perm filename COMMON.8[COM,LSP] blob
sn#821470 filedate 1986-07-28 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00748 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00104 00002
C00105 00003 ∂14-May-86 1033 LOOSEMORE@UTAH-20.ARPA rebinding of *evalhook*
C00107 00004 ∂14-May-86 1845 hpfclp!diamant@hplabs.ARPA re: rebinding of *evalhook*
C00110 00005 ∂15-May-86 1605 shebs@utah-cs.ARPA PCLS Available
C00115 00006 ∂15-May-86 1624 NGALL@G.BBN.COM adjusting displaced arrays
C00122 00007 ∂15-May-86 1959 NGALL@G.BBN.COM Is justification random?
C00125 00008 ∂16-May-86 1539 fateman@dali.berkeley.edu coercion of symbols to strings
C00127 00009 ∂17-May-86 1200 somewhere!yuasa@kurims.kurims.kyoto-u.junet
C00131 00010 ∂17-May-86 1218 DCP@ALLEGHENY.SCRC.Symbolics.COM adjusting displaced arrays
C00134 00011 ∂17-May-86 1724 FAHLMAN@C.CS.CMU.EDU Keyword extensions to Compile
C00137 00012 ∂18-May-86 0924 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK coercion from X to string
C00140 00013 ∂19-May-86 0918 gls@THINK-AQUINAS.ARPA coercion of symbols to strings
C00143 00014 ∂19-May-86 1743 FAHLMAN@C.CS.CMU.EDU coercion of symbols to strings
C00145 00015 ∂20-May-86 0022 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU coercion of symbols to strings
C00150 00016 ∂20-May-86 0825 fateman%dim@BERKELEY.EDU case using other equality-testing predicates
C00153 00017 ∂20-May-86 1012 DD60@A.CS.CMU.EDU CASE using other equality predicates
C00155 00018 ∂20-May-86 1133 DCP@ALLEGHENY.SCRC.Symbolics.COM case using other equality-testing predicates
C00160 00019 ∂20-May-86 1302 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM case using other equality-testing predicates
C00162 00020 ∂20-May-86 1418 KMP@SCRC-STONY-BROOK.ARPA Keyword extensions to Compile
C00172 00021 ∂20-May-86 1806 Gregor.pa@Xerox.COM Re: Keyword extensions to Compile
C00174 00022 ∂20-May-86 2009 Gregor.pa@Xerox.COM Re: Keyword extensions to Compile
C00176 00023 ∂20-May-86 2036 FAHLMAN@C.CS.CMU.EDU Keyword extensions to Compile
C00183 00024 ∂20-May-86 2046 FAHLMAN@C.CS.CMU.EDU case using other equality-testing predicates
C00186 00025 ∂20-May-86 2110 DT50@A.CS.CMU.EDU case-test
C00187 00026 ∂20-May-86 2123 FAHLMAN@C.CS.CMU.EDU case-test
C00189 00027 ∂20-May-86 2304 ELIOT%umass-cs.csnet@CSNET-RELAY.ARPA Coerce (Symbols)
C00191 00028 ∂21-May-86 1025 snyder%hplsny@hplabs.ARPA Re: Keyword extensions to Compile
C00194 00029 ∂21-May-86 1230 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM case using other equality-testing predicates
C00198 00030 ∂21-May-86 1252 REM@IMSSS Mismatch between name of function and what it really does
C00202 00031 ∂21-May-86 1315 Bobrow.pa@Xerox.COM Re: case using other equality-testing predicates
C00204 00032 ∂21-May-86 1316 Gregor.pa@Xerox.COM Re: Keyword extensions to Compile
C00207 00033 ∂21-May-86 1344 FAHLMAN@C.CS.CMU.EDU Keyword extensions to Compile
C00210 00034 ∂21-May-86 1346 DCP@SAPSUCKER.SCRC.Symbolics.COM Coerce (Symbols)
C00213 00035 ∂21-May-86 1357 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Porting Cl code
C00217 00036 ∂21-May-86 1406 hpfclp!diamant@hplabs.ARPA Re: Keyword extensions to Compile
C00222 00037 ∂21-May-86 1406 BSG@SCRC-STONY-BROOK.ARPA case using other equality-testing predicates
C00226 00038 ∂21-May-86 1526 JAR@AI.AI.MIT.EDU Keyword extensions to Compile
C00230 00039 ∂21-May-86 1606 Gregor.pa@Xerox.COM Re: case using other equality-testing predicates
C00233 00040 ∂21-May-86 1752 DCP@SAPSUCKER.SCRC.Symbolics.COM Re: case using other equality-testing predicates
C00237 00041 ∂21-May-86 2039 Hvatum.DLAB@MIT-MULTICS.ARPA (see below)
C00240 00042 ∂22-May-86 0002 somewhere!yuasa@kurims.kurims.kyoto-u.junet
C00243 00043 ∂22-May-86 0806 preece%ccvaxa@gswd-vms.ARPA Re: Keyword extensions to Compile
C00246 00044 ∂22-May-86 0959 KMP@SCRC-STONY-BROOK.ARPA Further remarks about portability
C00260 00045 ∂22-May-86 1614 hpfclp!diamant@hplabs.ARPA Re: Keyword extensions to Compile
C00268 00046 ∂22-May-86 1925 FAHLMAN@C.CS.CMU.EDU Where Pure Common Lisp lives
C00271 00047 ∂23-May-86 0507 DCP@SAPSUCKER.SCRC.Symbolics.COM Where Pure Common Lisp lives
C00273 00048 ∂23-May-86 0703 preece%ccvaxa@gswd-vms.ARPA Re: Where Pure Common Lisp lives
C00276 00049 ∂23-May-86 0735 FAHLMAN@C.CS.CMU.EDU Where Pure Common Lisp lives
C00278 00050 ∂23-May-86 0755 franz!fimass!jkf@kim.Berkeley.EDU list of lisp package external symbols
C00294 00051 ∂23-May-86 0834 SOLEY@XX.LCS.MIT.EDU Where Pure Common Lisp lives
C00297 00052 ∂23-May-86 0846 snyder%hplsny@hplabs.ARPA Re: Where Pure Common Lisp lives
C00300 00053 ∂23-May-86 0858 KMP@SCRC-STONY-BROOK.ARPA LISP:*LOCAL-PACKAGE*
C00309 00054 ∂23-May-86 1114 Moon@SCRC-QUABBIN.ARPA Where Pure Common Lisp lives
C00312 00055 ∂23-May-86 1152 greek%bach.decnet@hudson.dec.com Scott's comments on extensions
C00314 00056 ∂23-May-86 1206 FAHLMAN@C.CS.CMU.EDU Where Pure Common Lisp lives
C00317 00057 ∂23-May-86 1233 greek%bach.decnet@hudson.dec.com Momentary disengagement of brain.
C00318 00058 ∂23-May-86 1234 DSinger@SRI-KL.ARPA Pure CL, package names etc.
C00321 00059 ∂23-May-86 1253 snyder%hplsny@hplabs.ARPA Re: Scott's comments on extensions
C00324 00060 ∂23-May-86 1802 Hornig@ELEPHANT-BUTTE.SCRC.Symbolics.COM list of lisp package external symbols
C00326 00061 ∂23-May-86 1814 @SCRC-QUABBIN.ARPA,@EUPHRATES.SCRC.Symbolics.COM:Moon@SCRC-STONY-BROOK.ARPA Where Pure Common Lisp lives
C00329 00062 ∂23-May-86 2156 smh@mit-ems.ARPA Re: Where Pure Common Lisp lives
C00331 00063 ∂23-May-86 2156 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Common Lisp Subset
C00359 00064 ∂24-May-86 0950 RAM@C.CS.CMU.EDU Common Lisp Subset
C00366 00065 ∂24-May-86 1024 @MIT-LIVE-OAK.ARPA:JerryB@GOLD-HILL-ACORN.LCS.MIT.EDU Where Pure Common Lisp lives
C00369 00066 ∂24-May-86 1233 smh@mit-ems.ARPA Re: LISP:*LOCAL-PACKAGE*
C00373 00067 ∂24-May-86 1402 kempf%hplabsc@hplabs.ARPA Re: Common Lisp Subset
C00376 00068 ∂24-May-86 2312 hpfclp!diamant@hplabs.ARPA Re: LISP:*LOCAL-PACKAGE*
C00383 00069 ∂26-May-86 1801 FAHLMAN@C.CS.CMU.EDU Where we stand
C00391 00070 ∂27-May-86 0955 DCP@SAPSUCKER.SCRC.Symbolics.COM Re: Where Pure Common Lisp lives
C00393 00071 ∂27-May-86 1146 FAHLMAN@C.CS.CMU.EDU Keeping track of decisions
C00395 00072 ∂27-May-86 1355 LOOSEMORE@UTAH-20.ARPA portability
C00401 00073 ∂27-May-86 2206 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM MAKE-ECHO-STREAM, and related issues
C00405 00074 ∂27-May-86 2222 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM PEEK-CHAR
C00407 00075 ∂28-May-86 1609 Pavel.pa@Xerox.COM Is &body REALLY like &rest?
C00410 00076 ∂28-May-86 1742 somewhere!yuasa@kurims.kurims.kyoto-u.junet
C00413 00077 ∂28-May-86 2004 Moon@SCRC-QUABBIN.ARPA Are isomorphic structures EQUAL?
C00419 00078 ∂28-May-86 2230 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM *DEBUG-IO*
C00423 00079 ∂28-May-86 2243 franz!fimass!jkf@kim.Berkeley.EDU
C00425 00080 ∂29-May-86 0158 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Is &body REALLY like &rest?
C00432 00081 ∂29-May-86 0726 LOOSEMORE@UTAH-20.ARPA Apology
C00434 00082 ∂29-May-86 1332 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM *DEBUG-IO*
C00437 00083 ∂29-May-86 1339 NET-ORIGIN@MC.LCS.MIT.EDU Are isomorphic structures EQUAL?
C00441 00084 ∂29-May-86 1359 @BOETHIUS.THINK.COM:gls@AQUINAS.THINK.COM Is &body REALLY like &rest?
C00443 00085 ∂29-May-86 1430 DCP@SAPSUCKER.SCRC.Symbolics.COM *DEBUG-IO*
C00446 00086 ∂29-May-86 1450 RWK@SCRC-YUKON.ARPA keyword
C00448 00087 ∂29-May-86 1805 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Are isomorphic structures EQUAL?
C00452 00088 ∂29-May-86 1922 LOOSEMORE@UTAH-20.ARPA portability of pathnames
C00458 00089 ∂29-May-86 2121 miller.pa@Xerox.COM Some questions
C00462 00090 ∂29-May-86 2250 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM portability of pathnames
C00465 00091 ∂29-May-86 2317 somewhere!yuasa@kurims.kurims.kyoto-u.junet Sorry, KEYWORD should be there.
C00467 00092 ∂30-May-86 0029 RAM@C.CS.CMU.EDU Some questions
C00475 00093 ∂30-May-86 0053 RAM@C.CS.CMU.EDU Defstruct default values
C00477 00094 ∂30-May-86 0702 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA long-char, kanji
C00485 00095 ∂30-May-86 0848 preece%ccvaxa@gswd-vms.ARPA Defstruct default values
C00488 00096 ∂30-May-86 0926 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Some questions
C00491 00097 ∂30-May-86 1309 franz!fimass!jkf@kim.Berkeley.EDU Re: Some questions
C00495 00098 ∂30-May-86 1401 Moon@SCRC-QUABBIN.ARPA long-char, kanji
C00502 00099 ∂30-May-86 1947 FAHLMAN@C.CS.CMU.EDU long-char, kanji
C00510 00100 ∂30-May-86 1950 RAM@C.CS.CMU.EDU Defstruct default values
C00513 00101 ∂30-May-86 2047 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM long-char, kanji
C00524 00102 ∂30-May-86 2122 FAHLMAN@C.CS.CMU.EDU long-char, kanji
C00531 00103 ∂30-May-86 2235 FAHLMAN@C.CS.CMU.EDU Guidelines for the Standard
C00542 00104 ∂31-May-86 1028 RWK@ELEPHANT-BUTTE.SCRC.Symbolics.COM long-char, kanji
C00552 00105 ∂31-May-86 1811 FAHLMAN@C.CS.CMU.EDU long-char, kanji
C00558 00106 ∂01-Jun-86 1555 Bobrow.pa@Xerox.COM Re: Are isomorphic structures EQUAL?
C00561 00107 ∂01-Jun-86 2206 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA FORMAT Features
C00566 00108 ∂01-Jun-86 2253 REM@IMSSS CURSORPOS etc. directives
C00569 00109 ∂01-Jun-86 2258 REM@IMSSS oops
C00570 00110 ∂02-Jun-86 0059 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU long-char, kanji
C00575 00111 ∂02-Jun-86 0140 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Guidelines for the Standard
C00581 00112 ∂02-Jun-86 0737 shebs%utah-orion@utah-cs.arpa Re: long-char, kanji
C00583 00113 ∂02-Jun-86 0805 FAHLMAN@C.CS.CMU.EDU Guidelines for the Standard
C00588 00114 ∂02-Jun-86 0816 FAHLMAN@C.CS.CMU.EDU long-char, kanji
C00591 00115 ∂02-Jun-86 0838 robbins%bizet.decnet@hudson.dec.com RE: FORMAT Features
C00594 00116 ∂02-Jun-86 0846 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Common Lisp Subset
C00599 00117 ∂02-Jun-86 0905 SCHERLIS@C.CS.CMU.EDU please
C00600 00118 ∂02-Jun-86 0957 EVAN@SU-CSLI.ARPA Re: long-char, kanji
C00603 00119 ∂02-Jun-86 0958 DCP@SCRC-QUABBIN.ARPA please
C00605 00120 ∂02-Jun-86 1001 LOOSEMORE@UTAH-20.ARPA extending format
C00607 00121 ∂02-Jun-86 1441 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU please
C00609 00122 ∂02-Jun-86 1537 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM long-char, kanji
C00612 00123 ∂02-Jun-86 1831 RWK@ELEPHANT-BUTTE.SCRC.Symbolics.COM Common Lisp Subset
C00617 00124 ∂02-Jun-86 2058 mips!pachyderm.earl@su-glacier.arpa Re: Some questions
C00622 00125 ∂02-Jun-86 2114 fischer.pa@Xerox.COM Re: long-char, kanji
C00625 00126 ∂02-Jun-86 2120 RAM@C.CS.CMU.EDU Some questions
C00628 00127 ∂02-Jun-86 2232 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA New FORMAT Features
C00634 00128 ∂02-Jun-86 2329 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM tail recursion optimization
C00638 00129 ∂03-Jun-86 0002 RAM@C.CS.CMU.EDU tail recursion optimization
C00641 00130 ∂03-Jun-86 0151 somewhere!yuasa@kurims.kurims.kyoto-u.junet
C00647 00131 ∂03-Jun-86 0152 somewhere!hagiya@kurims.kurims.kyoto-u.junet long-char, kanji
C00652 00132 ∂03-Jun-86 0800 FAHLMAN@C.CS.CMU.EDU long-char, kanji
C00654 00133 ∂03-Jun-86 0815 FAHLMAN@C.CS.CMU.EDU long-char, kanji
C00659 00134 ∂03-Jun-86 0830 franz!fimass!jkf@kim.Berkeley.EDU Re: tail recursion optimization
C00661 00135 ∂03-Jun-86 1045 REM@IMSSS Flush bits from standard
C00666 00136 ∂03-Jun-86 1100 REM@IMSSS Bits for input, fonts for output
C00670 00137 ∂03-Jun-86 1114 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU type disjointness
C00673 00138 ∂03-Jun-86 1531 nuyens.pa@Xerox.COM re: long-char, kanji
C00680 00139 ∂03-Jun-86 1538 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU type disjointness
C00684 00140 ∂03-Jun-86 1601 mips!pachyderm.earl@su-glacier.arpa tail recursion optimization
C00688 00141 ∂03-Jun-86 2348 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Guidelines for the Standard
C00696 00142 ∂03-Jun-86 2357 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU long-char, kanji
C00699 00143 ∂04-Jun-86 0711 FAHLMAN@C.CS.CMU.EDU Guidelines for the Standard
C00702 00144 ∂04-Jun-86 0720 NGALL@G.BBN.COM Re: Are isomorphic structures EQUAL?
C00707 00145 ∂04-Jun-86 1210 LOOSEMORE@UTAH-20.ARPA a standardization proposal
C00712 00146 ∂04-Jun-86 1416 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU a standardization proposal
C00716 00147 ∂05-Jun-86 0623 @MCC.ARPA:krall%amethyst%mcc-pp@mcc a standardization proposal
C00720 00148 ∂05-Jun-86 0820 REM@IMSSS I claim subsetting doesn't kill portability
C00725 00149 ∂06-Jun-86 0116 somewhere!yuasa@kurims.kurims.kyoto-u.junet some questions
C00731 00150 ∂06-Jun-86 0331 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Re: long-char, kanji
C00738 00151 ∂08-Jun-86 2140 Hvatum.DLAB@MIT-MULTICS.ARPA Closure, Null Lexical Env.
C00741 00152 ∂09-Jun-86 0438 somewhere!hagiya@kurims.kurims.kyoto-u.junet long-char, kanji
C00746 00153 ∂09-Jun-86 0934 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA subset
C00750 00154 ∂09-Jun-86 1146 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM tail recursion optimization
C00757 00155 ∂09-Jun-86 1147 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Why aren't char bits portable?
C00766 00156 ∂09-Jun-86 1736 Miller.pa@Xerox.COM Re: Closure, Null Lexical Env.
C00769 00157 ∂09-Jun-86 1854 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: tail recursion optimization
C00772 00158 ∂10-Jun-86 0439 RAM@C.CS.CMU.EDU tail recursion optimization
C00776 00159 ∂10-Jun-86 0729 @GUIDO.THINK.COM:gls@AQUINAS.THINK.COM Re: tail recursion optimization
C00779 00160 ∂10-Jun-86 0751 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Re: Closure, Null Lexical Env.
C00784 00161 ∂10-Jun-86 0808 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Correction to reply to: Re: Closure, Null Lexical Env.
C00787 00162 ∂10-Jun-86 0830 franz!fimass!jkf@kim.Berkeley.EDU Re: tail recursion optimization
C00790 00163 ∂10-Jun-86 0858 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Some questions
C00793 00164 ∂10-Jun-86 1413 BRANDON@IBM.COM
C00794 00165 ∂10-Jun-86 1438 BRANDON@IBM.COM
C00795 00166 ∂10-Jun-86 1633 Miller.pa@Xerox.COM Re: Some questions
C00800 00167 ∂11-Jun-86 0002 nttlab!umemura@su-shasta.arpa Kanji, Foreign characters
C00805 00168 ∂11-Jun-86 0858 philbin-jim@YALE.ARPA Locales
C00807 00169 ∂11-Jun-86 0909 shebs%utah-orion@utah-cs.arpa Re: Some questions
C00811 00170 ∂11-Jun-86 1857 SCHERLIS@C.CS.CMU.EDU 1986 ACM Lisp and Fnl Pgg Conference
C00822 00171 ∂12-Jun-86 1130 SCHERLIS@C.CS.CMU.EDU Lisp Conference, addendum
C00824 00172 ∂16-Jun-86 0658 buy%bach.DEC@decwrl.DEC.COM packages and portability
C00834 00173 ∂16-Jun-86 0937 franz!fimass!jkf@kim.Berkeley.EDU Re: packages and portability
C00840 00174 ∂16-Jun-86 1016 Hvatum.DLAB@MIT-MULTICS.ARPA ' (lambda...)
C00845 00175 ∂16-Jun-86 1135 buy%bach.decnet@hudson.dec.com packages and portability
C00855 00176 ∂16-Jun-86 1402 pyramid!bein@SUN.COM compiled-function-p
C00857 00177 ∂16-Jun-86 1728 buy%bach.decnet@hudson.dec.com packages and portability
C00866 00178 ∂16-Jun-86 1958 FAHLMAN@C.CS.CMU.EDU compiled-function-p
C00869 00179 ∂16-Jun-86 2034 franz!fimass!jkf@kim.Berkeley.EDU Re: packages and portability
C00876 00180 ∂17-Jun-86 0618 BRANDON@IBM.COM Common LISP meeting at AAAI
C00877 00181 ∂17-Jun-86 0803 FAHLMAN@C.CS.CMU.EDU Common LISP meeting at AAAI
C00880 00182 ∂17-Jun-86 0853 VERACSD@USC-ISI.ARPA Re: packages and portability
C00881 00183 ∂17-Jun-86 1001 snyder%hplsny@hplabs.HP.COM Re: packages and portability
C00884 00184 ∂17-Jun-86 1336 DSinger@SRI-KL.ARPA The Reader and lower-case characters
C00886 00185 ∂17-Jun-86 1916 FAHLMAN@C.CS.CMU.EDU Out-of-range subsequences
C00888 00186 ∂17-Jun-86 1736 Daniels.pa@Xerox.COM Out-of-range subsequences
C00890 00187 ∂17-Jun-86 1709 FAHLMAN@C.CS.CMU.EDU The Reader and lower-case characters
C00892 00188 ∂17-Jun-86 2036 franz!fimass!jkf@kim.Berkeley.EDU Re: packages and portability
C00900 00189 ∂18-Jun-86 0523 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Out-of-range subsequences
C00902 00190 ∂18-Jun-86 0716 preece%ccvaxa@gswd-vms.ARPA Re: Out-of-range subsequences
C00905 00191 ∂18-Jun-86 0831 buy%bizet.decnet@hudson.dec.com packages and portability
C00915 00192 ∂18-Jun-86 0905 REM@IMSSS Achieving portability, how?
C00918 00193 ∂18-Jun-86 1228 @MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA Re: Out-of-range subsequences
C00921 00194 ∂18-Jun-86 1300 DLW@RIVERSIDE.SCRC.Symbolics.COM Re: Out-of-range subsequences
C00923 00195 ∂18-Jun-86 1345 franz!fimass!jkf@kim.Berkeley.EDU Re: packages and portability
C00928 00196 ∂18-Jun-86 1537 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Unsolicited typeout
C00934 00197 ∂18-Jun-86 1537 preece%ccvaxa@gswd-vms.ARPA Re: Out-of-range subsequences
C00936 00198 ∂18-Jun-86 1538 gls@Think.COM Out-of-range subsequences
C00939 00199 ∂18-Jun-86 1620 preece%ccvaxa@gswd-vms.ARPA Re: Out-of-range subsequences
C00941 00200 ∂18-Jun-86 1636 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Achieving portability, how?
C00943 00201 ∂18-Jun-86 1639 MILNES%cgi.csnet@CSNET-RELAY.ARPA Argument Lists
C00946 00202 ∂18-Jun-86 1708 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Unsolicited typeout
C00952 00203 ∂18-Jun-86 1721 gls@Think.COM Out-of-range subsequences
C00955 00204 ∂18-Jun-86 1954 NGALL@G.BBN.COM Re: Unsolicited typeout
C00959 00205 ∂18-Jun-86 2009 NGALL@G.BBN.COM Structure sharing
C00961 00206 ∂18-Jun-86 2029 FAHLMAN@C.CS.CMU.EDU What are special forms?
C00965 00207 ∂18-Jun-86 2037 FAHLMAN@C.CS.CMU.EDU Structure sharing
C00967 00208 ∂18-Jun-86 2041 preece%ccvaxa@gswd-vms.ARPA Unsolicited typeout
C00969 00209 ∂18-Jun-86 2106 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Structure sharing
C00973 00210 ∂18-Jun-86 2133 kddlab!yuasa@kurims.kurims.kyoto-u.junet What are special forms?
C00979 00211 ∂19-Jun-86 0003 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (MAKE-BROADCAST-STREAM)
C00981 00212 ∂19-Jun-86 0023 DT50@A.CS.CMU.EDU out-of-range subsequences
C00984 00213 ∂19-Jun-86 0744 Larry←Masinter.PARC@Xerox.COM Re: (MAKE-BROADCAST-STREAM)
C00986 00214 ∂19-Jun-86 0825 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM out-of-range subsequences
C00990 00215 ∂19-Jun-86 0838 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM (MAKE-BROADCAST-STREAM)
C00993 00216 ∂19-Jun-86 1303 Masinter.pa@Xerox.COM Re: Why aren't char bits portable?
C00995 00217 ∂19-Jun-86 1438 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Common LISP meeting at AAAI
C00997 00218 ∂20-Jun-86 0145 FAHLMAN@C.CS.CMU.EDU Common LISP meeting at AAAI
C00999 00219 ∂20-Jun-86 0154 gls@Think.COM out-of-range subsequences
C01004 00220 ∂20-Jun-86 0231 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Argument Lists
C01007 00221 ∂20-Jun-86 0231 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM packages and portability
C01009 00222 ∂20-Jun-86 0305 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Achieving portability, how?
C01011 00223 ∂20-Jun-86 0327 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Achieving portability, how?
C01013 00224 ∂20-Jun-86 0932 LOOSEMORE@UTAH-20.ARPA require
C01017 00225 ∂20-Jun-86 1210 REM@IMSSS Namestring&pathstring returning shared structure
C01020 00226 ∂20-Jun-86 1224 FAHLMAN@C.CS.CMU.EDU Namestring&pathstring returning shared structure
C01022 00227 ∂20-Jun-86 1441 snyder%hplsny@hplabs.HP.COM Re: require
C01026 00228 ∂20-Jun-86 1930 NGALL@G.BBN.COM defconstant
C01030 00229 ∂20-Jun-86 2004 FAHLMAN@C.CS.CMU.EDU defconstant
C01032 00230 ∂20-Jun-86 2126 mips!pachyderm.earl@su-glacier.arpa require
C01034 00231 ∂20-Jun-86 2153 Larry←Masinter.PARC@Xerox.COM Re: Namestring&pathstring returning shared structure
C01036 00232 ∂21-Jun-86 0033 OKUNO@SUMEX-AIM.ARPA negative index for the sequence
C01038 00233 ∂21-Jun-86 0108 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Common LISP meeting at Lisp Conference
C01041 00234 ∂21-Jun-86 0941 FAHLMAN@C.CS.CMU.EDU Namestring&pathstring returning shared structure
C01043 00235 ∂21-Jun-86 0942 OKUNO@SUMEX-AIM.ARPA negative index for the sequence (correction)
C01045 00236 ∂21-Jun-86 1337 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: Why aren't char bits portable?
C01048 00237 ∂21-Jun-86 1800 FAHLMAN@C.CS.CMU.EDU negative index for the sequence
C01050 00238 ∂21-Jun-86 1955 FAHLMAN@C.CS.CMU.EDU Argument Lists
C01054 00239 ∂21-Jun-86 2000 NGALL@G.BBN.COM Re: Namestring&pathstring returning shared structure
C01058 00240 ∂22-Jun-86 1431 snyder%hplsny@hplabs.HP.COM Re: Namestring&pathstring returning shared structure
C01060 00241 ∂22-Jun-86 1843 FAHLMAN@C.CS.CMU.EDU portability of pathnames
C01062 00242 ∂22-Jun-86 1843 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument Lists
C01069 00243 ∂22-Jun-86 1909 DT50@A.CS.CMU.EDU Re: Argument Lists
C01071 00244 ∂23-Jun-86 0706 DCP@RIVERSIDE.SCRC.Symbolics.COM Re: Namestring&pathstring returning shared structure
C01074 00245 ∂23-Jun-86 0813 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Re: Argument Lists
C01080 00246 ∂23-Jun-86 0814 NGALL@G.BBN.COM Re: portability of pathnames
C01088 00247 ∂23-Jun-86 0935 NGALL@G.BBN.COM Re: Argument Lists
C01092 00248 ∂23-Jun-86 1128 @MC.LCS.MIT.EDU:uucp@CCC.MIT.EDU
C01095 00249 ∂23-Jun-86 1305 FAHLMAN@C.CS.CMU.EDU Common Lisp 2000
C01101 00250 ∂23-Jun-86 1644 Pavel.pa@Xerox.COM Re: Namestring&pathstring returning shared structure
C01104 00251 ∂23-Jun-86 1655 Pavel.pa@Xerox.COM Re: Argument Lists
C01106 00252 ∂23-Jun-86 1716 jhl%hpljl@hplabs.HP.COM common lisp mailing list
C01107 00253 ∂23-Jun-86 1810 snyder%hplsny@hplabs.HP.COM Re: Namestring&pathstring returning shared structure
C01110 00254 ∂23-Jun-86 1816 Moon@QUABBIN.SCRC.Symbolics.COM Re: portability of pathnames
C01113 00255 ∂23-Jun-86 1823 FAHLMAN@C.CS.CMU.EDU Argument Lists
C01115 00256 ∂23-Jun-86 1831 KMP@YUKON.SCRC.Symbolics.COM portability of pathnames
C01134 00257 ∂23-Jun-86 1859 JAR@AI.AI.MIT.EDU Argument lists
C01138 00258 ∂23-Jun-86 1948 Pavel.pa@Xerox.COM Re: Argument Lists
C01140 00259 ∂23-Jun-86 1951 FAHLMAN@C.CS.CMU.EDU Argument lists
C01145 00260 ∂23-Jun-86 1959 FAHLMAN@C.CS.CMU.EDU Argument Lists
C01147 00261 ∂23-Jun-86 2216 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Error Checking in SUBSEQ
C01150 00262 ∂23-Jun-86 2225 MURRAY%cs.umass.edu@CSNET-RELAY.ARPA Argument-lists and friends
C01155 00263 ∂24-Jun-86 0002 nttlab!kurims!yuasa@kurims.kurims.kyoto-u.junet defconstant
C01162 00264 ∂24-Jun-86 0019 Pavel.pa@Xerox.COM Re: Argument Lists
C01164 00265 ∂24-Jun-86 0314 SARASWAT@C.CS.CMU.EDU Pl. put me on the list.
C01165 00266 ∂24-Jun-86 0808 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Argument Lists and ADVISE
C01168 00267 ∂24-Jun-86 0949 NGALL@G.BBN.COM Re: defconstant
C01172 00268 ∂24-Jun-86 1122 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument Lists
C01174 00269 ∂24-Jun-86 1225 DCP@QUABBIN.SCRC.Symbolics.COM raster graphics
C01178 00270 ∂24-Jun-86 1235 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Why are char bits portable?
C01188 00271 ∂24-Jun-86 1303 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Common Lisp 2000
C01190 00272 ∂24-Jun-86 1347 kempf%hplabsc@hplabs.HP.COM Re: raster graphics
C01191 00273 ∂24-Jun-86 1707 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument lists
C01196 00274 ∂24-Jun-86 1824 Pavel.pa@Xerox.COM Re: raster graphics
C01198 00275 ∂24-Jun-86 2036 NGALL@G.BBN.COM Re: Common Lisp 2000
C01201 00276 ∂25-Jun-86 1549 SCHMIDT@SUMEX-AIM.ARPA Lisp & FP conference siting
C01204 00277 ∂25-Jun-86 1947 JAR@AI.AI.MIT.EDU Argument lists
C01207 00278 ∂25-Jun-86 2156 GSB@AI.AI.MIT.EDU arglists, error checking
C01209 00279 ∂26-Jun-86 0732 gls@Think.COM Lisp & FP conference siting
C01217 00280 ∂26-Jun-86 0933 gls@Think.COM Argument lists: a proposal to shoot at
C01222 00281 ∂26-Jun-86 1618 NGALL@G.BBN.COM Re: Argument lists: a proposal to shoot at
C01228 00282 ∂26-Jun-86 1748 lee%hplles@hplabs.HP.COM Case sensitive reading.
C01230 00283 ∂26-Jun-86 1814 FAHLMAN@C.CS.CMU.EDU Case sensitive reading.
C01232 00284 ∂26-Jun-86 2014 FAHLMAN@C.CS.CMU.EDU Error Signalling
C01237 00285 ∂26-Jun-86 2052 FAHLMAN@C.CS.CMU.EDU Argument lists: a proposal to shoot at
C01239 00286 ∂27-Jun-86 0019 franz!fizzy!jkf@kim.Berkeley.EDU Re: Case sensitive reading.
C01241 00287 ∂27-Jun-86 0721 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Error Signalling
C01246 00288 ∂27-Jun-86 0722 kempf%hplabsc@hplabs.HP.COM Re: Case sensitive reading.
C01248 00289 ∂27-Jun-86 0738 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Re: Argument lists: a proposal to shoot at
C01252 00290 ∂27-Jun-86 0753 hall@HOPKINS-EECS-BRAVO.ARPA Getting on the mailing list.
C01254 00291 ∂27-Jun-86 1144 gls@Think.COM Re: Argument lists: a proposal to shoot at
C01257 00292 ∂27-Jun-86 1334 NGALL@G.BBN.COM Re: Argument lists: a proposal to shoot at
C01261 00293 ∂27-Jun-86 1518 Moon@RIVERSIDE.SCRC.Symbolics.COM Re: Argument lists: a proposal to shoot at
C01266 00294 ∂27-Jun-86 1523 Moon@QUABBIN.SCRC.Symbolics.COM Error Signalling
C01269 00295 ∂27-Jun-86 1532 DSinger@SRI-KL.ARPA Re: Argument Lists
C01271 00296 ∂27-Jun-86 1627 KMP@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-MAX-ARGS,etc
C01274 00297 ∂27-Jun-86 1636 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Error Signalling
C01280 00298 ∂27-Jun-86 1639 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument lists: a proposal to shoot at
C01284 00299 ∂27-Jun-86 1705 FAHLMAN@C.CS.CMU.EDU Error Signalling
C01287 00300 ∂27-Jun-86 1733 DCP@QUABBIN.SCRC.Symbolics.COM Error Signalling
C01291 00301 ∂27-Jun-86 1734 DCP@QUABBIN.SCRC.Symbolics.COM Error Signalling
C01295 00302 ∂28-Jun-86 1531 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA DRIBBLE
C01299 00303 ∂28-Jun-86 2100 LOOSEMORE@UTAH-20.ARPA Re: portability of pathnames
C01303 00304 ∂29-Jun-86 0846 griss%hplmlg@hplabs.HP.COM Re: Argument lists: a proposal to shoot at
C01305 00305 ∂29-Jun-86 1058 Masinter.pa@Xerox.COM
C01313 00306 ∂29-Jun-86 1109 shebs%utah-orion@utah-cs.arpa Re: portability of pathnames
C01318 00307 ∂29-Jun-86 1117 shebs%utah-orion@utah-cs.arpa Re: portability of pathnames
C01321 00308 ∂29-Jun-86 1124 shebs%utah-orion@utah-cs.arpa Re: Argument Lists
C01325 00309 ∂29-Jun-86 1150 shebs%utah-orion@utah-cs.arpa Re: Error Signalling
C01328 00310 ∂29-Jun-86 1154 Bobrow.pa@Xerox.COM Re: portability of pathnames
C01330 00311 ∂29-Jun-86 1231 FAHLMAN@C.CS.CMU.EDU Error Signalling
C01333 00312 ∂29-Jun-86 1620 LOOSEMORE@UTAH-20.ARPA Error signalling
C01336 00313 ∂29-Jun-86 1710 shebs%utah-orion@utah-cs.arpa Re: Error Signalling
C01340 00314 ∂29-Jun-86 1954 franz!fizzy!jkf@kim.Berkeley.EDU Re: Error Signalling
C01344 00315 ∂29-Jun-86 1959 FAHLMAN@C.CS.CMU.EDU Error signalling
C01350 00316 ∂29-Jun-86 1959 FAHLMAN@C.CS.CMU.EDU DRIBBLE
C01355 00317 ∂29-Jun-86 2201 NGALL@G.BBN.COM Re: DRIBBLE
C01362 00318 ∂29-Jun-86 2235 NGALL@G.BBN.COM Re: Argument lists: a proposal to shoot at
C01368 00319 ∂29-Jun-86 2311 NGALL@G.BBN.COM Re: Argument lists: a proposal to shoot at
C01374 00320 ∂30-Jun-86 0619 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: Error Signalling
C01378 00321 ∂30-Jun-86 0619 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM two functions for everything
C01380 00322 ∂30-Jun-86 0751 franz!fizzy!jkf@kim.Berkeley.EDU Re: Error Signalling
C01382 00323 ∂30-Jun-86 0754 LOOSEMORE@UTAH-20.ARPA Two functions for everything?
C01385 00324 ∂30-Jun-86 0937 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA DRIBBLE
C01389 00325 ∂30-Jun-86 1011 LOOSEMORE@UTAH-20.ARPA Re: Two functions for everything?
C01394 00326 ∂30-Jun-86 1040 FAHLMAN@C.CS.CMU.EDU Two functions for everything?
C01398 00327 ∂30-Jun-86 1057 gls@Think.COM Re: Argument lists: a proposal to shoot at
C01404 00328 ∂30-Jun-86 1103 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: Two functions for everything?
C01411 00329 ∂30-Jun-86 1149 JAR@AI.AI.MIT.EDU Argument lists: a proposal to shoot at
C01413 00330 ∂30-Jun-86 1216 gls@Think.COM Argument lists: a proposal to shoot at
C01416 00331 ∂30-Jun-86 1301 LOOSEMORE@UTAH-20.ARPA Re: Two functions for everything?
C01421 00332 ∂30-Jun-86 1443 DESMEDT%HNYKUN52.BITNET@WISCVM.ARPA request to join
C01423 00333 ∂30-Jun-86 1748 Masinter.pa@Xerox.COM signalling errors
C01425 00334 ∂30-Jun-86 1859 FAHLMAN@C.CS.CMU.EDU signalling errors
C01428 00335 ∂30-Jun-86 2025 FAHLMAN@C.CS.CMU.EDU Argument lists
C01434 00336 ∂01-Jul-86 0350 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA function keys
C01439 00337 ∂01-Jul-86 0556 Hvatum.DLAB@MIT-MULTICS.ARPA subseq
C01441 00338 ∂01-Jul-86 0640 NGALL@G.BBN.COM Re: Argument lists
C01444 00339 ∂01-Jul-86 0714 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Argument lists
C01450 00340 ∂01-Jul-86 0825 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU
C01459 00341 ∂01-Jul-86 0836 FAHLMAN@C.CS.CMU.EDU subseq
C01461 00342 ∂01-Jul-86 0839 FAHLMAN@C.CS.CMU.EDU Argument lists
C01463 00343 ∂01-Jul-86 0901 FAHLMAN@C.CS.CMU.EDU Argument lists
C01468 00344 ∂01-Jul-86 0955 gls@Think.COM Argument lists
C01471 00345 ∂01-Jul-86 0958 gls@Think.COM Argument lists
C01473 00346 ∂01-Jul-86 1104 Bobrow.pa@Xerox.COM Re: Argument lists
C01475 00347 ∂01-Jul-86 1108 Gregor.pa@Xerox.COM Re: Argument lists
C01477 00348 ∂01-Jul-86 1335 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM function keys
C01479 00349 ∂01-Jul-86 1335 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument lists
C01482 00350 ∂01-Jul-86 1338 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Argument lists
C01488 00351 ∂01-Jul-86 1429 berman@vaxa.isi.edu Validation status
C01493 00352 ∂01-Jul-86 1527 FAHLMAN@C.CS.CMU.EDU Validation status
C01495 00353 ∂01-Jul-86 1638 KMP@STONY-BROOK.SCRC.Symbolics.COM Argument lists
C01498 00354 ∂01-Jul-86 1935 FAHLMAN@C.CS.CMU.EDU Open keyboard, insert foot.
C01501 00355 ∂02-Jul-86 0535 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Portability and Code walkers
C01504 00356 ∂02-Jul-86 0615 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA function keys
C01508 00357 ∂02-Jul-86 0837 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Argument lists
C01513 00358 ∂02-Jul-86 0842 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Argument lists
C01518 00359 ∂02-Jul-86 0915 FAHLMAN@C.CS.CMU.EDU Argument lists
C01521 00360 ∂02-Jul-86 1057 RICE@SUMEX-AIM.ARPA Types of Functions
C01523 00361 ∂02-Jul-86 1102 Gregor.pa@Xerox.COM Re: Portability and Code walkers
C01526 00362 ∂02-Jul-86 1214 FAHLMAN@C.CS.CMU.EDU Portability and Code walkers
C01529 00363 ∂02-Jul-86 1352 Masinter.pa@Xerox.COM underspecified type-of
C01532 00364 ∂02-Jul-86 1415 FAHLMAN@C.CS.CMU.EDU underspecified type-of
C01534 00365 ∂02-Jul-86 1512 hall@HOPKINS-EECS-BRAVO.ARPA Removal from mailing list.
C01535 00366 ∂02-Jul-86 1656 FAHLMAN@C.CS.CMU.EDU Types of Functions
C01537 00367 ∂02-Jul-86 1737 FAHLMAN@C.CS.CMU.EDU Argument lists
C01542 00368 ∂02-Jul-86 1752 Daniels.pa@Xerox.COM Re: underspecified type-of
C01543 00369 ∂02-Jul-86 1925 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument lists
C01550 00370 ∂02-Jul-86 1946 FAHLMAN@C.CS.CMU.EDU Argument lists
C01552 00371 ∂02-Jul-86 1958 FAHLMAN@C.CS.CMU.EDU Argument lists
C01555 00372 ∂02-Jul-86 2311 NGALL@G.BBN.COM Re: Types of Functions
C01558 00373 ∂02-Jul-86 2330 NGALL@G.BBN.COM Re: Argument lists
C01563 00374 ∂03-Jul-86 0013 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Speed of FUNCTION-PARAMETER-RANGE
C01567 00375 ∂03-Jul-86 0226 DESMEDT%HNYKUN52.BITNET@WISCVM.ARPA withdrawal from mailing list
C01569 00376 ∂03-Jul-86 0608 @MIT-LIVE-OAK.ARPA:JerryB@GOLD-HILL-ACORN.LCS.MIT.EDU Speed of FUNCTION-PARAMETER-RANGE
C01572 00377 ∂03-Jul-86 0619 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Re: Types of Functions
C01575 00378 ∂03-Jul-86 0624 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Re: Types of Functions
C01577 00379 ∂03-Jul-86 0630 FAHLMAN@C.CS.CMU.EDU Types of Functions
C01579 00380 ∂03-Jul-86 0841 snyder%hplsny@hplabs.HP.COM Re: Argument lists
C01582 00381 ∂03-Jul-86 1417 masinter.pa@Xerox.COM Re: Types of Functions
C01585 00382 ∂05-Jul-86 1654 Pavel.pa@Xerox.COM DECLARE SPECIAL Considered Confusing
C01591 00383 ∂06-Jul-86 1112 DCP@QUABBIN.SCRC.Symbolics.COM subst-if-not and nsubst-if-not, programming folk-lore
C01595 00384 ∂06-Jul-86 1113 DCP@QUABBIN.SCRC.Symbolics.COM Two functions for everything?
C01599 00385 ∂06-Jul-86 1152 @UR-ACORN.ARPA,@UR-BEECHNUT.ARPA:miller@UR-ACORN.ARPA subst-if-not and nsubst-if-not, programming folk-lore
C01603 00386 ∂06-Jul-86 1501 RPG Object-Oriented Programming Meeting at L&FP
C01605 00387 ∂07-Jul-86 0704 DCP@QUABBIN.SCRC.Symbolics.COM DECLARE SPECIAL Considered Confusing
C01607 00388 ∂07-Jul-86 0708 gls@Think.COM Re: Argument lists: a proposal to shoot at
C01609 00389 ∂07-Jul-86 0712 alatto@BBNCC5.ARPA Re: subst-if-not and nsubst-if-not, programming folk-lore
C01614 00390 ∂07-Jul-86 0713 DCP@QUABBIN.SCRC.Symbolics.COM subst-if-not and nsubst-if-not, programming folk-lore
C01620 00391 ∂07-Jul-86 0730 gls@Think.COM subst-if-not and nsubst-if-not, programming folk-lore
C01623 00392 ∂07-Jul-86 0810 DCP@QUABBIN.SCRC.Symbolics.COM subst-if-not and nsubst-if-not, programming folk-lore
C01627 00393 ∂07-Jul-86 1015 Masinter.pa@Xerox.COM Re: subst-if-not and nsubst-if-not, programming folk-lore
C01629 00394 ∂07-Jul-86 1127 FAHLMAN@C.CS.CMU.EDU Argument lists
C01633 00395 ∂07-Jul-86 1144 gls@Think.COM Argument lists
C01636 00396 ∂07-Jul-86 1206 FAHLMAN@C.CS.CMU.EDU Argument lists
C01638 00397 ∂07-Jul-86 1212 @MIT-LIVE-OAK.ARPA:JAR@MIT-AI.ARPA compiler-let
C01645 00398 ∂07-Jul-86 1249 shebs%utah-orion@utah-cs.arpa Re: compiler-let
C01649 00399 ∂07-Jul-86 1507 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: compiler-let
C01651 00400 ∂07-Jul-86 1614 shebs%utah-orion@utah-cs.arpa Re: compiler-let
C01655 00401 ∂07-Jul-86 1733 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM compiler-let
C01661 00402 ∂07-Jul-86 1816 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM DECLARE SPECIAL Considered Confusing
C01670 00403 ∂07-Jul-86 1945 NGALL@G.BBN.COM Re: DECLARE SPECIAL Considered Confusing
C01674 00404 ∂07-Jul-86 2016 Moon@QUABBIN.SCRC.Symbolics.COM DECLARE SPECIAL Considered Confusing
C01684 00405 ∂08-Jul-86 1003 hpfclp!diamant@hplabs.HP.COM compiler-let
C01689 00406 ∂08-Jul-86 1003 gls@Think.COM [gls@Think.COM: Re: compiler-let]
C01693 00407 ∂08-Jul-86 1257 snyder%hplsny@hplabs.HP.COM Re: Compiler recognizing uses of only two values
C01697 00408 ∂08-Jul-86 1355 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: DECLARE SPECIAL Considered Confusing
C01700 00409 ∂08-Jul-86 1832 FAHLMAN@C.CS.CMU.EDU Editorial Comment
C01702 00410 ∂09-Jul-86 0653 DLW@QUABBIN.SCRC.Symbolics.COM compiler-let
C01705 00411 ∂09-Jul-86 0810 loral!jvz@sdcsvax.ucsd.edu
C01707 00412 ∂09-Jul-86 1014 gls@Think.COM Editorial Comment
C01709 00413 ∂09-Jul-86 1024 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: DECLARE SPECIAL
C01711 00414 ∂09-Jul-86 1032 berman@vaxa.isi.edu Re: Editorial Comment
C01712 00415 ∂09-Jul-86 1218 wft@gandalf.cs.cmu.edu Concurrent Lisp
C01714 00416 ∂09-Jul-86 1341 LOOSEMORE@UTAH-20.ARPA more editorial comment on format
C01717 00417 ∂09-Jul-86 1555 jvz@sdcsvax.ucsd.edu mailing list
C01718 00418 ∂10-Jul-86 0124 @AI.AI.MIT.EDU:STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU more editorial comment on format
C01721 00419 ∂10-Jul-86 0331 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA GC, exit-to-system
C01727 00420 ∂10-Jul-86 0854 MICHAEL@CS.COLUMBIA.EDU A minimal Common Lisp interpreter.
C01728 00421 ∂10-Jul-86 1016 unido!uklirb!przy@seismo.CSS.GOV Mailing-list
C01731 00422 ∂10-Jul-86 1051 FAHLMAN@C.CS.CMU.EDU A minimal Common Lisp interpreter.
C01734 00423 ∂10-Jul-86 1320 LOOSEMORE@UTAH-20.ARPA extra lambda list keywords
C01736 00424 ∂10-Jul-86 1414 DCP@STONY-BROOK.SCRC.Symbolics.COM extra lambda list keywords
C01741 00425 ∂10-Jul-86 1440 FAHLMAN@C.CS.CMU.EDU extra lambda list keywords
C01743 00426 ∂10-Jul-86 1545 LOOSEMORE@UTAH-20.ARPA portable code walkers vs. portable code
C01748 00427 ∂10-Jul-86 1705 Masinter.pa@Xerox.COM functionp
C01750 00428 ∂10-Jul-86 1747 James←W.←Rich.DlosLV@Xerox.COM Re: Editorial Comment
C01752 00429 ∂10-Jul-86 1804 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM GC, exit-to-system
C01755 00430 ∂10-Jul-86 1928 FAHLMAN@C.CS.CMU.EDU GC, exit-to-system
C01758 00431 ∂10-Jul-86 2201 raible@AMES-NAS.ARPA please add me
C01759 00432 ∂10-Jul-86 2233 franz!fizzy!jkf@kim.Berkeley.EDU Re: GC, exit-to-system
C01762 00433 ∂10-Jul-86 2248 masinter.PA@Xerox.COM Re: GC, exit-to-system
C01766 00434 ∂11-Jul-86 0242 @MIT-GOLDILOCKS.ARPA:SR.LAURITZEN@SPEECH.MIT.EDU compiler-let
C01770 00435 ∂11-Jul-86 0651 smh@mit-ems.ARPA Re: portable code walkers vs. portable code
C01774 00436 ∂11-Jul-86 0715 greek%bach.DEC@decwrl.DEC.COM Our MUFCSPC entry.
C01776 00437 ∂11-Jul-86 0728 shebs%utah-orion@utah-cs.arpa Re: GC, exit-to-system
C01780 00438 ∂11-Jul-86 0815 FAHLMAN@C.CS.CMU.EDU compiler-let
C01783 00439 ∂11-Jul-86 0858 FAHLMAN@C.CS.CMU.EDU GC, exit-to-system
C01786 00440 ∂11-Jul-86 0935 gls@Think.COM portable code walkers vs. portable code
C01790 00441 ∂11-Jul-86 1000 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Re: GC, exit-to-system
C01795 00442 ∂11-Jul-86 1038 liz@brillig.umd.edu portable code walkers
C01799 00443 ∂11-Jul-86 1057 LOOSEMORE@UTAH-20.ARPA Re: portable code walkers vs. portable code
C01802 00444 ∂11-Jul-86 1546 Masinter.pa@Xerox.COM Re: portable code walkers
C01805 00445 ∂11-Jul-86 1601 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM portable code walkers vs. portable code
C01810 00446 ∂11-Jul-86 1601 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM functionp
C01814 00447 ∂11-Jul-86 1822 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM GC, exit-to-system
C01816 00448 ∂11-Jul-86 1843 Pavel.pa@Xerox.COM Re: DECLARE SPECIAL Considered Confusing
C01824 00449 ∂11-Jul-86 2019 FAHLMAN@C.CS.CMU.EDU DECLARE SPECIAL Considered Confusing
C01827 00450 ∂11-Jul-86 2042 JAR@AI.AI.MIT.EDU DECLARE SPECIAL Considered Confusing
C01828 00451 ∂11-Jul-86 2142 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA A minimal Common Lisp interpreter.
C01831 00452 ∂12-Jul-86 0508 DCP@QUABBIN.SCRC.Symbolics.COM Re: GC, exit-to-system
C01837 00453 ∂12-Jul-86 0536 SARASWAT@C.CS.CMU.EDU KCl vs KCN
C01838 00454 ∂12-Jul-86 0754 franz!fizzy!jkf@kim.Berkeley.EDU Re: GC, exit-to-system
C01841 00455 ∂12-Jul-86 1618 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: DECLARE SPECIAL Considered Confusing
C01844 00456 ∂12-Jul-86 1948 FAHLMAN@C.CS.CMU.EDU DECLARE SPECIAL Considered Confusing
C01849 00457 ∂12-Jul-86 2142 Pavel.pa@Xerox.COM Re: DECLARE SPECIAL Considered Confusing
C01854 00458 ∂13-Jul-86 1404 Masinter.pa@Xerox.COM Re: functionp
C01858 00459 ∂13-Jul-86 1510 FAHLMAN@C.CS.CMU.EDU functionp
C01860 00460 ∂13-Jul-86 1608 FAHLMAN@C.CS.CMU.EDU Decisions
C01867 00461 ∂13-Jul-86 1750 FAHLMAN@C.CS.CMU.EDU Decisions and Discussions
C01870 00462 ∂13-Jul-86 1802 FAHLMAN@C.CS.CMU.EDU Proposal #1
C01875 00463 ∂13-Jul-86 1815 FAHLMAN@C.CS.CMU.EDU Proposals 2, 3, & 4
C01882 00464 ∂13-Jul-86 1818 FAHLMAN@C.CS.CMU.EDU Oops
C01883 00465 ∂13-Jul-86 1953 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #1
C01889 00466 ∂13-Jul-86 2034 FAHLMAN@C.CS.CMU.EDU Proposal #1
C01893 00467 ∂13-Jul-86 2120 RAM@C.CS.CMU.EDU Proposals 2, 3, & 4
C01896 00468 ∂13-Jul-86 2129 Masinter.pa@Xerox.COM Re: Proposal #1
C01899 00469 ∂13-Jul-86 2148 Masinter.pa@Xerox.COM Proposal #1 - minor revision
C01903 00470 ∂13-Jul-86 2204 FAHLMAN@C.CS.CMU.EDU Proposals 2, 3, & 4
C01907 00471 ∂13-Jul-86 2211 STANKULI%cs.umass.edu@CSNET-RELAY.ARPA Golden Hill Common Lisp installation on DEC Rainbow
C01914 00472 ∂14-Jul-86 0723 shebs%utah-orion@utah-cs.arpa Re: Proposals 2, 3, & 4
C01917 00473 ∂14-Jul-86 0756 LOOSEMORE@UTAH-20.ARPA proposal #1
C01921 00474 ∂14-Jul-86 0843 FAHLMAN@C.CS.CMU.EDU proposal #1
C01924 00475 ∂14-Jul-86 0925 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #1
C01927 00476 ∂14-Jul-86 1021 Marilyn←Hodgetts.ROCH@Xerox.COM DL
C01928 00477 ∂14-Jul-86 1100 LOOSEMORE@UTAH-20.ARPA proposal #1 again
C01930 00478 ∂14-Jul-86 1100 DLW@QUABBIN.SCRC.Symbolics.COM Proposal #1 - minor revision
C01933 00479 ∂14-Jul-86 1159 bradley@ATHENA.MIT.EDU please take me off
C01934 00480 ∂14-Jul-86 1257 @MCC.COM:krall%pp@mcc.arpa Re: Proposals 2, 3, & 4
C01937 00481 ∂14-Jul-86 1113 franz!fizzy!jkf@kim.Berkeley.EDU Re: Proposals 2, 3, & 4
C01940 00482 ∂14-Jul-86 1124 FAHLMAN@C.CS.CMU.EDU Proposals 2, 3, & 4
C01943 00483 ∂14-Jul-86 1142 FAHLMAN@C.CS.CMU.EDU proposal #1 again
C01946 00484 ∂14-Jul-86 1342 RWK@YUKON.SCRC.Symbolics.COM Re: GC, exit-to-system
C01949 00485 ∂14-Jul-86 1347 RWK@YUKON.SCRC.Symbolics.COM Re: DECLARE SPECIAL Considered Confusing
C01952 00486 ∂14-Jul-86 1452 Pavel.pa@Xerox.COM Re: DECLARE SPECIAL Considered Confusing
C01955 00487 ∂14-Jul-86 1500 JAR@AI.AI.MIT.EDU DECLARE SPECIAL Considered Confusing
C01959 00488 ∂14-Jul-86 1553 franz!fizzy!jkf@kim.Berkeley.EDU Re: GC, exit-to-system
C01962 00489 ∂14-Jul-86 1658 franz!fizzy!jkf@kim.Berkeley.EDU Re: Proposals 2, 3, & 4
C01966 00490 ∂14-Jul-86 1753 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM GC, exit-to-system
C01973 00491 ∂14-Jul-86 1846 FAHLMAN@C.CS.CMU.EDU Proposals 2, 3, & 4
C01977 00492 ∂14-Jul-86 1932 kessler%utah-orion@utah-cs.arpa Definition time macros
C01980 00493 ∂14-Jul-86 1944 kessler%utah-orion@utah-cs.arpa GC and BYE
C01983 00494 ∂14-Jul-86 2316 oster%ucblapis@BERKELEY.EDU DESCRIBE-ARGUMENTS
C01985 00495 ∂15-Jul-86 0055 Pavel.pa@Xerox.COM Re: DESCRIBE-ARGUMENTS
C01987 00496 ∂15-Jul-86 0713 FAHLMAN@C.CS.CMU.EDU DESCRIBE-ARGUMENTS
C01990 00497 ∂15-Jul-86 0722 @MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA Re: DESCRIBE-ARGUMENTS
C01993 00498 ∂15-Jul-86 0738 FAHLMAN@C.CS.CMU.EDU Definition time macros
C01999 00499 ∂15-Jul-86 0752 kessler%cons@utah-cs.arpa Definition time macros
C02004 00500 ∂15-Jul-86 0854 franz!fizzy!jkf@kim.Berkeley.EDU Re: Proposals 2, 3, & 4
C02011 00501 ∂15-Jul-86 0903 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: GC, exit-to-system
C02015 00502 ∂15-Jul-86 1031 @MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA Definition time macros
C02019 00503 ∂15-Jul-86 1157 FAHLMAN@C.CS.CMU.EDU Definition time macros
C02021 00504 ∂15-Jul-86 1242 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Definition time macros
C02026 00505 ∂15-Jul-86 1531 FAHLMAN@C.CS.CMU.EDU Definition time macros
C02028 00506 ∂15-Jul-86 1619 RAM@C.CS.CMU.EDU Proposals 2, 3, & 4
C02034 00507 ∂15-Jul-86 1651 snyder%hplsny@hplabs.HP.COM Re: Definition time macros
C02038 00508 ∂15-Jul-86 1805 Masinter.pa@Xerox.COM Proposals 2, 3, & 4
C02045 00509 ∂15-Jul-86 1825 FAHLMAN@C.CS.CMU.EDU Definition time macros
C02048 00510 ∂15-Jul-86 1848 RAM@C.CS.CMU.EDU Proposals 2, 3, & 4
C02051 00511 ∂15-Jul-86 2040 FAHLMAN@C.CS.CMU.EDU Feh!
C02054 00512 ∂15-Jul-86 2216 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Definition time macros
C02057 00513 ∂15-Jul-86 2226 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Function-Parameter-names
C02059 00514 ∂15-Jul-86 2313 RAM@C.CS.CMU.EDU
C02061 00515 ∂16-Jul-86 0822 FAHLMAN@C.CS.CMU.EDU
C02063 00516 ∂16-Jul-86 1119 Parker.ES@Xerox.COM Tail Recursion in Common Lisp ???
C02065 00517 ∂16-Jul-86 1242 Parker.ES@Xerox.COM Re: Tail Recursion in Common Lisp ???
C02067 00518 ∂16-Jul-86 1249 FAHLMAN@C.CS.CMU.EDU Tail Recursion in Common Lisp ???
C02069 00519 ∂16-Jul-86 1337 willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Definition time macros
C02075 00520 ∂16-Jul-86 1421 RPG Object-oriented-Programming Meeting at L&FP
C02076 00521 ∂16-Jul-86 1427 bond!m42!jap%ux63.bath.ac.uk@Cs.Ucl.AC.UK
C02079 00522 ∂16-Jul-86 2043 OKUNO@SUMEX-AIM.ARPA RE: easier addressing for EuLISP discussions
C02081 00523 ∂17-Jul-86 0754 BSG@ELEPHANT-BUTTE.SCRC.Symbolics.COM Tail Recursion in Common Lisp ???
C02084 00524 ∂17-Jul-86 0816 FAHLMAN@C.CS.CMU.EDU Tail Recursion in Common Lisp ???
C02087 00525 ∂17-Jul-86 0901 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Tail Recursion in Common Lisp ???
C02090 00526 ∂17-Jul-86 1239 NGALL@G.BBN.COM APPEND and NCONC
C02091 00527 ∂17-Jul-86 1358 REM@IMSSS Expanding macros more than once?
C02093 00528 ∂17-Jul-86 1900 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Tail Recursion in Common Lisp ???
C02097 00529 ∂17-Jul-86 1939 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Tail Recursion in Common Lisp ???
C02103 00530 ∂18-Jul-86 0903 cscott@bfly-vax.bbn.com Re: Tail Recursion in Common Lisp ???
C02107 00531 ∂18-Jul-86 0944 FAHLMAN@C.CS.CMU.EDU Tail Recursion in Common Lisp ???
C02110 00532 ∂18-Jul-86 1029 bradley@Think.COM Re: Tail Recursion in Common Lisp ???
C02114 00533 ∂18-Jul-86 1058 cscott@bfly-vax.bbn.com Re: Tail Recursion in Common Lisp ???
C02116 00534 ∂18-Jul-86 1102 Masinter.pa@Xerox.COM Re: Tail Recursion in Common Lisp ???
C02118 00535 ∂18-Jul-86 1343 RICE@SUMEX-AIM.ARPA Tail Recursion.
C02120 00536 ∂18-Jul-86 1645 REM@IMSSS No need to optimize tail recursion, use infinite virtual stack!
C02122 00537 ∂18-Jul-86 2039 willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Tail Recursion in Common Lisp ???
C02125 00538 ∂18-Jul-86 2129 FAHLMAN@C.CS.CMU.EDU Tail Recursion in Common Lisp ???
C02127 00539 ∂18-Jul-86 2216 HELLER%cs.umass.edu@CSNET-RELAY.ARPA Question about the function DOCUMENTATION
C02130 00540 ∂19-Jul-86 0909 FAHLMAN@C.CS.CMU.EDU Question about the function DOCUMENTATION
C02132 00541 ∂19-Jul-86 1428 NGALL@G.BBN.COM Re: DECLARE SPECIAL Considered Confusing
C02144 00542 ∂19-Jul-86 2058 DCP@QUABBIN.SCRC.Symbolics.COM get-setf-method takes optional environment argument
C02147 00543 ∂19-Jul-86 2132 RAM@C.CS.CMU.EDU get-setf-method takes optional environment argument
C02149 00544 ∂20-Jul-86 1048 JAR@AI.AI.MIT.EDU No need to optimize tail recursion, use infinite virtual stack!
C02153 00545 ∂20-Jul-86 1103 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (setf (not x) y) => (setf x (not y))
C02156 00546 ∂20-Jul-86 1217 FAHLMAN@C.CS.CMU.EDU (setf (not x) y) => (setf x (not y))
C02158 00547 ∂20-Jul-86 1248 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (setf (not x) y) => (setf x (not y))
C02163 00548 ∂20-Jul-86 1310 @UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA Re: (setf (not x) y) => (setf x (not y))
C02164 00549 ∂20-Jul-86 1411 ALAN@AI.AI.MIT.EDU DECLARE SPECIAL Considered Confusing
C02166 00550 ∂20-Jul-86 1553 NGALL@G.BBN.COM Re: DECLARE SPECIAL Considered Confusing
C02171 00551 ∂20-Jul-86 2134 FAHLMAN@C.CS.CMU.EDU Proposals
C02174 00552 ∂21-Jul-86 0832 HASSETT%sperry-csd.csnet@CSNET-RELAY.ARPA GC function
C02177 00553 ∂21-Jul-86 1104 greek%bach.decnet@hudson.dec.com A Bit More on Lambda-List Parsing
C02180 00554 ∂21-Jul-86 1125 greek%bach.decnet@hudson.dec.com Scope of Declarations.
C02182 00555 ∂21-Jul-86 1147 gls@Think.COM DESCRIBE-ARGUMENTS or, special variables considered disgusting
C02185 00556 ∂21-Jul-86 1147 greek%bach.decnet@hudson.dec.com Declarations
C02187 00557 ∂21-Jul-86 1201 gls@Think.COM Re: exit-to-system
C02191 00558 ∂21-Jul-86 1301 ALAN@AI.AI.MIT.EDU DECLARE SPECIAL Considered Confusing
C02195 00559 ∂21-Jul-86 1347 greek%bach.decnet@hudson.dec.com Bawden's Alternate Proposal
C02197 00560 ∂21-Jul-86 1431 gls@Think.COM Tail Recursion in Common Lisp ???
C02201 00561 ∂21-Jul-86 1432 cscott@bfly-vax.bbn.com exit-to-system
C02203 00562 ∂21-Jul-86 1453 ALAN@AI.AI.MIT.EDU Bawden's Alternate Proposal
C02205 00563 ∂21-Jul-86 1526 NGALL@G.BBN.COM Re: Declarations
C02209 00564 ∂21-Jul-86 1647 masinter.PA@Xerox.COM (declare (type fixnum ---)) considered etc.
C02211 00565 ∂21-Jul-86 1745 FAHLMAN@C.CS.CMU.EDU (declare (type fixnum ---)) considered etc.
C02213 00566 ∂21-Jul-86 1846 FAHLMAN@C.CS.CMU.EDU Some easy ones (?)
C02225 00567 ∂21-Jul-86 1906 masinter.pa@Xerox.COM Re: (declare (type fixnum ---)) considered etc.
C02228 00568 ∂21-Jul-86 2211 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Declare Special
C02232 00569 ∂21-Jul-86 2218 Masinter.pa@Xerox.COM Re: Some easy ones (?)
C02235 00570 ∂21-Jul-86 2355 Masinter.pa@Xerox.COM Re: exit-to-system
C02238 00571 ∂22-Jul-86 0725 greek%bach.decnet@hudson.dec.com Declarations
C02240 00572 ∂22-Jul-86 0850 @REAGAN.AI.MIT.EDU:MLY@AI.AI.MIT.EDU Proposal #5
C02244 00573 ∂22-Jul-86 0927 greek%bach.decnet@hudson.dec.com The Noncontroversial Ten Proposals
C02246 00574 ∂22-Jul-86 0953 gls@Think.COM (setf (not x) y) => (setf x (not y))
C02248 00575 ∂22-Jul-86 1024 RWK@YUKON.SCRC.Symbolics.COM (setf (not x) y) => (setf x (not y))
C02251 00576 ∂22-Jul-86 1034 Daniels.pa@Xerox.COM Re: Some easy ones (?)
C02253 00577 ∂22-Jul-86 1436 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Bawden's Alternate Proposal
C02257 00578 ∂22-Jul-86 1437 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
C02260 00579 ∂22-Jul-86 1449 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Some easy ones (?) -- 107 lines of answer (!)
C02270 00580 ∂22-Jul-86 1505 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM GC function
C02275 00581 ∂22-Jul-86 1532 DCP@STONY-BROOK.SCRC.Symbolics.COM (setf (not x) y) => (setf x (not y))
C02278 00582 ∂22-Jul-86 1539 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (setf (not x) y) => (setf x (not y))
C02282 00583 ∂22-Jul-86 1548 bane.pa@Xerox.COM setf of nthcdr?
C02283 00584 ∂22-Jul-86 2112 NGALL@G.BBN.COM Re: Declarations
C02285 00585 ∂22-Jul-86 2135 NGALL@G.BBN.COM Re: Declare Special
C02291 00586 ∂22-Jul-86 2140 hpfclp!diamant@hplabs.HP.COM Structure sharing in arguments
C02295 00587 ∂22-Jul-86 2218 ALAN@AI.AI.MIT.EDU Bawden's Alternate Proposal
C02298 00588 ∂23-Jul-86 0002 NGALL@G.BBN.COM Re: DECLARE SPECIAL Considered Confusing
C02303 00589 ∂22-Jul-86 2332 NGALL@G.BBN.COM Re: Some easy ones (?)
C02323 00590 ∂23-Jul-86 0045 masinter.pa@Xerox.COM Re: Bawden's Alternate Proposal
C02327 00591 ∂23-Jul-86 0418 edsel!bhopal!jonl@navajo.stanford.edu DECLARE SPECIAL Considered Confusing ?
C02331 00592 ∂23-Jul-86 0650 RAM@C.CS.CMU.EDU THE VALUES
C02334 00593 ∂23-Jul-86 0720 shebs%utah-orion@utah-cs.arpa Re: Some easy ones (?)
C02338 00594 ∂23-Jul-86 0740 RAM@C.CS.CMU.EDU (declare (type fixnum ---)) considered etc.
C02342 00595 ∂23-Jul-86 0814 shebs%utah-orion@utah-cs.arpa Re: (declare (type fixnum ---)) considered etc.
C02344 00596 ∂23-Jul-86 0904 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Computer Implementations Sociologists
C02349 00597 ∂23-Jul-86 0931 gls@Think.COM (declare (type fixnum ---)) considered etc.
C02351 00598 ∂23-Jul-86 0946 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
C02357 00599 ∂23-Jul-86 0949 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA JIS WG start in japan
C02361 00600 ∂23-Jul-86 0955 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM THE VALUES
C02365 00601 ∂23-Jul-86 1009 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: Some easy ones (?)
C02372 00602 ∂23-Jul-86 1022 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Structure sharing in arguments
C02377 00603 ∂23-Jul-86 1135 vanroggen%bach.decnet@hudson.dec.com proposals 5-14
C02380 00604 ∂23-Jul-86 1154 DLW@QUABBIN.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
C02383 00605 ∂23-Jul-86 1158 DLW@QUABBIN.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
C02385 00606 ∂23-Jul-86 1231 Cassels@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: (declare (type fixnum ---)) considered etc.
C02389 00607 ∂23-Jul-86 1245 greek%bach.decnet@hudson.dec.com Oops, sorry.
C02390 00608 ∂23-Jul-86 1258 RAM@C.CS.CMU.EDU (declare (type fixnum ---)) considered etc.
C02392 00609 ∂23-Jul-86 1409 FREEMAN@SUMEX-AIM.ARPA Re: Some easy ones (?)
C02395 00610 ∂23-Jul-86 1549 masinter.pa@Xerox.COM Re: (declare (type fixnum ---)) considered etc.
C02398 00611 ∂23-Jul-86 1630 kempf%hplabsc@hplabs.HP.COM Recursive Compilation?
C02401 00612 ∂23-Jul-86 1819 JAR@AI.AI.MIT.EDU Recursive Compilation?
C02403 00613 ∂23-Jul-86 1843 NGALL@G.BBN.COM Re: Some easy ones (?)
C02406 00614 ∂23-Jul-86 1904 NGALL@G.BBN.COM Re: Declaration before variable
C02410 00615 ∂23-Jul-86 1930 NGALL@G.BBN.COM Re: Some easy ones (?)
C02414 00616 ∂23-Jul-86 1943 NGALL@G.BBN.COM Re: THE VALUES
C02419 00617 ∂23-Jul-86 2021 NGALL@G.BBN.COM Re: (declare (type fixnum ---)) considered etc.
C02422 00618 ∂23-Jul-86 2038 NGALL@g.bbn.com Re: DECLARE SPECIAL Considered Confusing ?
C02427 00619 ∂23-Jul-86 2101 NGALL@G.BBN.COM Re: Bawden's Alternate Proposal
C02432 00620 ∂23-Jul-86 2101 NGALL@G.BBN.COM Re: Proposal about lambda-list params
C02433 00621 ∂23-Jul-86 2124 NGALL@G.BBN.COM Re: exit-to-system
C02436 00622 ∂23-Jul-86 2126 NGALL@G.BBN.COM Re: GC function
C02439 00623 ∂24-Jul-86 0328 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA &BODY
C02444 00624 ∂24-Jul-86 0653 gls@Think.COM (declare (type fixnum ---)) considered etc.
C02447 00625 ∂24-Jul-86 0829 Cassels@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
C02452 00626 ∂24-Jul-86 0921 @UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA Structure sharing in arguments
C02459 00627 ∂24-Jul-86 0947 snyder%hplsny@hplabs.HP.COM Re: (declare (type fixnum ---)) considered etc.
C02463 00628 ∂24-Jul-86 0959 ANDY@Sushi.Stanford.EDU Re: Some easy ones (?)
C02467 00629 ∂24-Jul-86 1011 ALR%OZ.AI.MIT.EDU@AI.AI.MIT.EDU REDUCE args
C02469 00630 ∂24-Jul-86 1026 shebs%utah-orion@utah-cs.arpa Re: (declare (type fixnum ---)) considered etc.
C02473 00631 ∂24-Jul-86 1037 DCP@QUABBIN.SCRC.Symbolics.COM Re: (declare (type fixnum ---)) considered etc.
C02479 00632 ∂24-Jul-86 1043 NGALL@G.BBN.COM Re: REDUCE args
C02481 00633 ∂24-Jul-86 1050 shebs%utah-orion@utah-cs.arpa Re: (declare (type fixnum ---)) considered etc.
C02485 00634 ∂24-Jul-86 1100 DCP@QUABBIN.SCRC.Symbolics.COM Re: Some easy ones (?)
C02491 00635 ∂24-Jul-86 1101 Cassels@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
C02497 00636 ∂24-Jul-86 1130 RAM@C.CS.CMU.EDU (declare (type fixnum ---)) considered etc.
C02500 00637 ∂24-Jul-86 1133 DCP@QUABBIN.SCRC.Symbolics.COM Structure sharing in arguments
C02509 00638 ∂24-Jul-86 1206 STEVER%OZ.AI.MIT.EDU@AI.AI.MIT.EDU Declaration before variable
C02511 00639 ∂24-Jul-86 1219 DCP@QUABBIN.SCRC.Symbolics.COM Re: REDUCE args
C02514 00640 ∂24-Jul-86 1321 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: (declare (type fixnum ---)) considered etc.
C02521 00641 ∂24-Jul-86 1244 @UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA Re: REDUCE args
C02524 00642 ∂24-Jul-86 1244 SCHERLIS@C.CS.CMU.EDU Lisp Conference, continued
C02526 00643 ∂24-Jul-86 1402 FAHLMAN@C.CS.CMU.EDU REDUCE args
C02528 00644 ∂24-Jul-86 1402 NGALL@G.BBN.COM Re: Lisp Conference, continued
C02531 00645 ∂24-Jul-86 1539 edsel!bhopal!jonl@navajo.stanford.edu UNSPECIAL
C02533 00646 ∂24-Jul-86 1539 DSinger@SRI-KL.ARPA The (not special) declaration
C02536 00647 ∂24-Jul-86 1543 NGALL@G.BBN.COM Re: Some easy ones (?)
C02544 00648 ∂24-Jul-86 1543 DSinger@SRI-KL.ARPA without-gc-delay
C02546 00649 ∂24-Jul-86 1547 DSinger@SRI-KL.ARPA Case of symbols and their print-names
C02548 00650 ∂24-Jul-86 1549 FAHLMAN@C.CS.CMU.EDU FIXNUM considered useful
C02552 00651 ∂24-Jul-86 1547 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
C02555 00652 ∂24-Jul-86 1605 edsel!bhopal!jonl@navajo.stanford.edu (declare (type fixnum ---)) considered etc.
C02558 00653 ∂24-Jul-86 1605 edsel!bhopal!jonl@navajo.stanford.edu Status of declare UNSPECIAL
C02560 00654 ∂24-Jul-86 1740 FAHLMAN@C.CS.CMU.EDU Case of symbols and their print-names
C02562 00655 ∂24-Jul-86 1804 FAHLMAN@C.CS.CMU.EDU Status of declare UNSPECIAL
C02564 00656 ∂24-Jul-86 2011 FAHLMAN@C.CS.CMU.EDU Structure sharing in arguments
C02568 00657 ∂24-Jul-86 2020 FAHLMAN@C.CS.CMU.EDU Structure sharing in arguments
C02570 00658 ∂24-Jul-86 2036 FAHLMAN@C.CS.CMU.EDU Declaration before variable
C02573 00659 ∂24-Jul-86 2051 FAHLMAN@C.CS.CMU.EDU Some easy ones (?)
C02575 00660 ∂24-Jul-86 2131 DT50@A.CS.CMU.EDU duplicate names in LET*
C02578 00661 ∂24-Jul-86 2236 franz!smh@kim.Berkeley.EDU (declare (type fixnum ---)) considered etc.
C02580 00662 ∂24-Jul-86 2248 NGALL@G.BBN.COM Re: duplicate names in LET*
C02583 00663 ∂25-Jul-86 0519 vanroggen%bach.decnet@hudson.dec.com duplicate LET* variables
C02585 00664 ∂25-Jul-86 0654 Skef@Think.COM Re: REDUCE args
C02589 00665 ∂25-Jul-86 0754 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM FIXNUM considered useful
C02592 00666 ∂25-Jul-86 0809 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Status of declare UNSPECIAL
C02594 00667 ∂25-Jul-86 0839 FAHLMAN@C.CS.CMU.EDU FIXNUM considered useful
C02597 00668 ∂25-Jul-86 0843 DCP@QUABBIN.SCRC.Symbolics.COM Re: REDUCE args
C02599 00669 ∂25-Jul-86 0911 DCP@QUABBIN.SCRC.Symbolics.COM Re: Some easy ones (?)
C02602 00670 ∂25-Jul-86 0922 Skef@Think.COM Re: REDUCE args
C02605 00671 ∂25-Jul-86 1026 willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Proposal #13: Structure Sharing in Arguments
C02608 00672 ∂25-Jul-86 1127 shebs%utah-orion@utah-cs.arpa Re: Proposal #13: Structure Sharing in Arguments
C02613 00673 ∂25-Jul-86 1157 @MC.LCS.MIT.EDU:uucp@CCC.MIT.EDU
C02616 00674 ∂25-Jul-86 1214 gls@Think.COM Structure sharing in arguments
C02621 00675 ∂25-Jul-86 1233 REM@IMSSS Accidental clobbering of pnames etc.
C02625 00676 ∂25-Jul-86 1454 gls@Think.COM Re: REDUCE args
C02628 00677 ∂25-Jul-86 1454 gls@Think.COM duplicate names in LET*
C02630 00678 ∂25-Jul-86 1714 Masinter.pa@Xerox.COM Re: FIXNUM considered useful
C02633 00679 ∂25-Jul-86 2027 ANDY@Sushi.Stanford.EDU Re: Some easy ones (?)
C02639 00680 ∂25-Jul-86 2034 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
C02646 00681 ∂26-Jul-86 0759 FAHLMAN@C.CS.CMU.EDU Some easy ones (?)
C02653 00682 ∂26-Jul-86 0954 NGALL@G.BBN.COM Re: Some easy ones (?)
C02656 00683 ∂26-Jul-86 1054 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #13: Structure Sharing in Arguments
C02658 00684 ∂26-Jul-86 1127 ANDY@Sushi.Stanford.EDU Re: Some easy ones (?)
C02661 00685 ∂26-Jul-86 1257 FAHLMAN@C.CS.CMU.EDU Some easy ones (?)
C02665 00686 ∂26-Jul-86 1308 RPG An Etiquette Request from your Mailing List Maintainer
C02668 00687 ∂26-Jul-86 1344 FAHLMAN@C.CS.CMU.EDU Proposal #13: Structure Sharing in Arguments
C02672 00688 ∂26-Jul-86 1411 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #13: Structure Sharing in Arguments
C02676 00689 ∂26-Jul-86 1433 FAHLMAN@C.CS.CMU.EDU Proposal #13: Structure Sharing in Arguments
C02679 00690 ∂26-Jul-86 1626 FAHLMAN@C.CS.CMU.EDU Mailing list etiquette
C02690 00691 ∂26-Jul-86 1626 shebs%utah-orion@utah-cs.arpa Re: Proposal #13: Structure Sharing in Arguments
C02693 00692 ∂26-Jul-86 1824 masinter.PA@Xerox.COM Re: Some easy ones (?)
C02696 00693 ∂26-Jul-86 1855 FAHLMAN@C.CS.CMU.EDU Some easy ones (?)
C02698 00694 ∂26-Jul-86 1913 ALAN@AI.AI.MIT.EDU Some easy ones (?)
C02700 00695 ∂26-Jul-86 2202 SAFIER%cgi.csnet@CSNET-RELAY.ARPA RE: Proposal 13
C02703 00696 ∂26-Jul-86 2227 FAHLMAN@C.CS.CMU.EDU Proposal 13
C02705 00697 ∂26-Jul-86 2253 FAHLMAN@C.CS.CMU.EDU Rules clarification
C02708 00698 ∂27-Jul-86 0936 FAHLMAN@C.CS.CMU.EDU Summary of current issues
C02712 00699 ∂27-Jul-86 1156 RPG Possible New Issues
C02717 00700 ∂27-Jul-86 1307 RPG Possible New Issues
C02720 00701 ∂27-Jul-86 1523 FAHLMAN@C.CS.CMU.EDU Proposal #5 status
C02727 00702 ∂27-Jul-86 1554 lmi-angel!rpk@EDDIE.MIT.EDU TYPE-SPECIFIER-P
C02729 00703 ∂27-Jul-86 1637 FAHLMAN@C.CS.CMU.EDU TYPE-SPECIFIER-P
C02731 00704 ∂27-Jul-86 1807 lmi-angel!rpk@EDDIE.MIT.EDU PARSE-BODY
C02733 00705 ∂27-Jul-86 1807 FAHLMAN@C.CS.CMU.EDU Proposal #6 Status: Parsing in &BODY
C02736 00706 ∂27-Jul-86 1810 ALAN@AI.AI.MIT.EDU Ordering suggestion
C02738 00707 ∂27-Jul-86 1838 FAHLMAN@C.CS.CMU.EDU PARSE-BODY
C02740 00708 ∂27-Jul-86 1845 FAHLMAN@C.CS.CMU.EDU Proposal #7 Status: TYPE-SPECIFIER-P
C02743 00709 ∂27-Jul-86 1851 FAHLMAN@C.CS.CMU.EDU Proposal #8 Status: Clarifications to DEFCONSTANT
C02744 00710 ∂27-Jul-86 1902 FAHLMAN@C.CS.CMU.EDU Proposal #9 Status: Variable Name Conflicts
C02747 00711 ∂27-Jul-86 1917 FAHLMAN@C.CS.CMU.EDU Staus of proposals 10, 11, and 12
C02749 00712 ∂27-Jul-86 1956 RPG New entries on Common-Lisp
C02753 00713 ∂27-Jul-86 2001 FAHLMAN@C.CS.CMU.EDU Proposal #13: Structure Sharing in Arguments
C02758 00714 ∂27-Jul-86 2008 masinter.PA@Xerox.COM Re: Proposal #5 status
C02760 00715 ∂27-Jul-86 2008 FAHLMAN@C.CS.CMU.EDU Remaining issues
C02762 00716 ∂27-Jul-86 2045 Miller.pa@Xerox.COM Re: Proposal #9B suggested modification
C02763 00717 ∂27-Jul-86 2046 masinter.PA@Xerox.COM Re: discussion
C02765 00718 ∂27-Jul-86 2126 RPG Common-Lisp-Request@SU-AI
C02767 00719 ∂27-Jul-86 2303 RPG Re: Common Lisp Mailing List
C02769 00720 ∂28-Jul-86 0814 gls@Think.COM Proposal #13: Structure Sharing in Arguments
C02772 00721 ∂28-Jul-86 0912 LOOSEMORE@UTAH-20.ARPA proposal #6 (&body parsing)
C02774 00722 ∂28-Jul-86 0922 LOOSEMORE@UTAH-20.ARPA proposal #5 (parse-body)
C02776 00723 ∂28-Jul-86 0944 hoey@nrl-aic Re: Proposal #13: Structure Sharing in Arguments
C02779 00724 ∂28-Jul-86 0953 RPG Possible New Issues
C02784 00725 ∂28-Jul-86 1147 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #9 Status: Variable Name Conflicts
C02787 00726 ∂28-Jul-86 1147 DCP@QUABBIN.SCRC.Symbolics.COM Re: REDUCE args
C02795 00727 ∂28-Jul-86 1153 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #5 status
C02806 00728 ∂28-Jul-86 1155 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #5 status
C02818 00729 ∂28-Jul-86 1220 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #7 Status: TYPE-SPECIFIER-P
C02823 00730 ∂28-Jul-86 1222 DCP@STONY-BROOK.SCRC.Symbolics.COM Staus of proposals 10, 11, and 12
C02825 00731 ∂28-Jul-86 1224 FAHLMAN@C.CS.CMU.EDU Proposal #9 Status: Variable Name Conflicts
C02827 00732 ∂28-Jul-86 1220 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #13: Structure Sharing in Arguments
C02835 00733 ∂28-Jul-86 1224 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #6 Status: Parsing in &BODY
C02840 00734 ∂28-Jul-86 1301 Masinter.pa@Xerox.COM Re: Proposal #7 Status: TYPE-SPECIFIER-P
C02844 00735 ∂28-Jul-86 1358 RICE@SUMEX-AIM.ARPA Proposal #7A - Type-Specifier-P
C02846 00736 ∂28-Jul-86 1416 Masinter.pa@Xerox.COM Re: PARSE-BODY
C02850 00737 ∂28-Jul-86 1524 VERACSD@A.ISI.EDU Re: Remaining issues
C02851 00738 ∂28-Jul-86 1624 Masinter.pa@Xerox.COM Re: Proposal #6 Status: Parsing in &BODY
C02854 00739 ∂28-Jul-86 1624 Masinter.pa@Xerox.COM Re: Proposal #9: Variable Name Conflicts
C02856 00740 ∂28-Jul-86 1830 ALAN@AI.AI.MIT.EDU Proposal #9: Variable Name Conflicts
C02859 00741 ∂28-Jul-86 1839 FAHLMAN@C.CS.CMU.EDU proposal #6 (&body parsing)
C02862 00742 ∂28-Jul-86 1848 FAHLMAN@C.CS.CMU.EDU [gls: Proposal #7 amendment]
C02866 00743 ∂28-Jul-86 2016 FAHLMAN@C.CS.CMU.EDU Proposal #5 status
C02870 00744 ∂28-Jul-86 2044 FAHLMAN@C.CS.CMU.EDU Proposal #7 Status: TYPE-SPECIFIER-P
C02872 00745 ∂28-Jul-86 2053 FAHLMAN@C.CS.CMU.EDU Staus of proposals 10, 11, and 12
C02874 00746 ∂28-Jul-86 2055 NGALL@G.BBN.COM Re: Proposal #5 status
C02881 00747 ∂28-Jul-86 2227 FAHLMAN@C.CS.CMU.EDU Proposed moratorium
C02883 00748 ∂28-Jul-86 2308 RPG Mail Traffic
C02885 ENDMK
C⊗;
∂14-May-86 1033 LOOSEMORE@UTAH-20.ARPA rebinding of *evalhook*
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 14 May 86 10:09:33 PDT
Date: Wed 14 May 86 11:10:23-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: rebinding of *evalhook*
To: common-lisp@SU-AI.ARPA
Message-ID: <12206660792.25.LOOSEMORE@UTAH-20.ARPA>
Comment: Remailed at SU-AI after delay caused by mailing list error.
A PCLS user has pointed out that it is basically impossible to setq
*evalhook* from the toploop. The manual (p. 322) clearly states that
"both *evalhook* and *applyhook* are rebound to the value nil around the
invocation of the hook function", so this is how we've implemented eval.
Our toploop uses the ordinary eval function, just like everybody else.
Once you setq *evalhook* from the toploop, therefore, the hook function
gets called every time you type anything in. What's more, because of
the rebinding, it's impossible to setq *evalhook* back to NIL so that
the hook function doesn't get called anymore.
Do other implementations do anything special to avoid this situation?
-Sandra
-------
∂14-May-86 1845 hpfclp!diamant@hplabs.ARPA re: rebinding of *evalhook*
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 14 May 86 18:45:08 PDT
Received: by hplabs.ARPA ; Wed, 14 May 86 18:45:12 pdt
Date: Wed, 14 May 86 18:45:12 pdt
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: re: rebinding of *evalhook*
From: SANDRA <hplabs!LOOSEMORE@UTAH-20.ARPA>
Our toploop uses the ordinary eval function, just like everybody else.
Once you setq *evalhook* from the toploop, therefore, the hook function
gets called every time you type anything in. What's more, because of
the rebinding, it's impossible to setq *evalhook* back to NIL so that
the hook function doesn't get called anymore.
This is quite correct. It is impossible to reset the value of *evalhook*
from inside the hook function.
Do other implementations do anything special to avoid this situation?
We (at HP) have a command available always (called "Abort") which places
the user back in the default toploop, which, among other things, turns off the
eval hook function. For example, inside a break loop, it is possible either
to quit (which essentially takes you one level out), or abort to top level.
After abort has been executed, the value of *evalhook* will again be nil.
∂15-May-86 1605 shebs@utah-cs.ARPA PCLS Available
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 15 May 86 15:55:08 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA23739; Thu, 15 May 86 16:56:56 MDT
Date: Thu, 15 May 86 16:56:56 MDT
From: shebs@utah-cs.arpa (Stanley Shebs)
Message-Id: <8605152256.AA23739@utah-cs.ARPA>
To: common-lisp@su-ai.arpa
Subject: PCLS Available
This is to announce the availability of the Portable Common Lisp Subset
(PCLS), a Common Lisp subset developed at the University of Utah which
runs in Portable Standard Lisp (PSL).
PCLS is a large subset which implements about 550 of the 620+ Common Lisp
functions. It lacks lexical closures, ratios, and complex numbers. Streams
and characters are actually small integers, some of the special forms
are missing, and a number of functions (such as FORMAT) lack many of the
more esoteric options. PCLS does include a fully working package system,
multiple values, lambda keywords, lexical scoping, and most data types
(including hash tables, arrays, structures, pathnames, and random states).
The PCLS compiler is the PSL compiler which produces very efficient code,
augmented by a frontend that does a number of optimizations specific to
Common Lisp. Gabriel benchmarks and others show that PCLS programs can
be made to run as fast as their PSL counterparts - almost all uses of
lambda keywords are optimized away, and a type declaration/inference
optimizer replaces many function calls with efficient PSL equivalents.
PCLS has been used at Utah and elsewhere for about 6 months, and a number
of programs have been ported both to and from PCLS and other Common Lisps.
PCLS is being distributed along with an updated version of PSL (3.2a).
We require that you sign a site license agreement. The distribution fee
is $250 US for nonprofit institutions, plus a $750 license fee for
corporations. Full sources to both PSL and PCLS are included along with
documentation on the internals and externals of the system. At present,
we are distributing PCLS for 4.2/4.3 BSD Vax Un*x and for Vax VMS.
Releases for Apollo and Sun are anticipated soon, and versions for other
PSL implementations are likely. If interested, send your USnail address to:
Loretta Cruse
Computer Science Department, 3160 MEB
University of Utah
Salt Lake City UT 84112
cruse@utah-20.ARPA {seismo, ihnp4, decvax}!utah-cs!cruse.UUCP
Technical questions about PCLS, flames about absence of closures, etc
may be directed to shebs@utah-cs.ARPA, loosemore@utah-20.ARPA, or
kessler@utah-cs.ARPA.
∂15-May-86 1624 NGALL@G.BBN.COM adjusting displaced arrays
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 15 May 86 16:24:10 PDT
Date: 15 May 1986 19:26-EDT
Sender: NGALL@G.BBN.COM
Subject: adjusting displaced arrays
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]15-May-86 19:26:22.NGALL>
The following appears in Guy's list of `clarifications':
(*) 293 ...Add a function DISPLACED-ARRAY-P, which takes an array and
returns NIL and 0 if it is not displaced or the array displaced to and
the displaced-index-offset if it is displaced. These allow certain code
efficiencies, and also allow array displacement to be explained in
terms of Lisp primitives:
(DEFUN AREF (ORIGINAL-ARRAY &REST SUBSCRIPTS)
(LABELS ((FOO (ARRAY INDEX)
(MULTIPLE-VALUE-BIND (NEW-ARRAY OFFSET) (DISPLACED-ARRAY-P ARRAY)
(IF (NULL NEW-ARRAY)
(ROW-MAJOR-AREF ARRAY INDEX)
(MULTIPLE-VALUE-CALL #'FOO
NEW-ARRAY
(+ INDEX OFFSET)))))
(FOO ORIGINAL-ARRAY
(APPLY #'ARRAY-ROW-MAJOR-INDEX ORIGINAL-ARRAY SUBSCRIPTS))))
As a bow to efficiency, note the fact that if array A is displaced to B
with offset M, and B is displaced to C with offset N, and B is not
adjustable, then DISPLACED-ARRAY-P of A might return either array B with
offset M or array C with offset (+ M N). This generalizes to chains
of non-adjustable arrays.
----------
I would like to add an additional (and I think stronger) argument for
DISPLACED-ARRAY-P. Someone in our group had the following type of
problem: Given a very long string (representing, say, a long report),
he wanted to be able to displace a char. string of length N (call it
N-char-string) (where 1 <= N <= 80) to the beginning
of the very-long-string, do some parsing of the N-char-string, and
then ADJUST the N-char-string to start where it had previously ended
and to have a new length. In other words, he wanted to slide this
variable length window over the very-long-string. Without
DISPLACED-ARRAY-P, he is forced to wrap a structure around the
displaced-array to record the
original array the current offset, even though the displaced array
structure already contains this info!
I would suggest one minor change to DISPLACED-ARRAY-P, in the case
that it returns NIL, I suggest that it should return only that (and
not return the 0). The zero provides no information and does not seem
to be of any use.
----------
(*) 297 Here are the interactions of ADJUST-ARRAY with displacement.
Suppose we are adjusting array A, which is perhaps displaced
to B before adjustment and perhaps to C after adjustment.
(1) Not displaced before or after. The dimensions of A are altered, and
the contents rearranged as appropriate. Additional elements of A are
taken from the :initial-element. The use of :initial-contents causes
all old contents to be discarded.
(2) Not displaced before, but displaced afterwards to C. As already
specified, none of the original contents of A appears in A afterwards,
but rather the contents of C without any rearrangement of C.
(3) Displaced beforehand to B, and afterward to C. As in case (2), no
contents of B appear in A afterward. If :DISPLACED-INDEX-OFFSET is not
specified in this case, it defaults to zero; the old offset (into B) is
not retained.
(4) Displaced beforehand to B, but not displaced afterward. A gets a
new "data region", and contents of B are copied into it as appropriate
to maintain the existing old contents; additional elements of A are
taken from the :initial-element. However, the use of :initial-contents
causes all old contents to be discarded.
----------
In case (3), what if (eq B C)? (this would be the case in the sliding
window above). Saying that "no contents of B appear in A afterward"
is not true.
-- Nick
∂15-May-86 1959 NGALL@G.BBN.COM Is justification random?
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 15 May 86 19:59:29 PDT
Date: 15 May 1986 23:01-EDT
Sender: NGALL@G.BBN.COM
Subject: Is justification random?
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]15-May-86 23:01:44.NGALL>
I wanted to use format to lay out some column headers like this:
| xxx | xxx | xxx | ...
| yyy | yyy | yyy | ...
I assumed that the ~<...~> format directives would fit the bill. When
I tried it on VaxLisp, I discovered that their FORMAT randomizes the
dispersion of whitespace (their code actually calls a random number
generator). Their rationale is that doing so will prevent whitespace
from clumping on the left if ~<...~> were used to put out a paragraph
of text.
The Symbolics CL does not randomize, it inserts spaces from left to
right. I guess their rationale (really mine) is that it makes column
header layout work right (a much more common use of ~<...~>).
CLtL is ambiguous. It merely says "the spacing is evenly divided
between the text segments" (pg. 404)
Here is a brief test case:
(dotimes (i 10) (format t "~&~3:<x~;|~>"))
On the Vax, the x is not in the same column each time. On the SCL it
is.
I think the behavior of ~<...~> should be standardized and I vote
against randomization.
-- Nick
∂16-May-86 1539 fateman@dali.berkeley.edu coercion of symbols to strings
Received: from DALI.Berkeley.EDU by SU-AI.ARPA with TCP; 16 May 86 15:39:05 PDT
Received: by dali.berkeley.edu (5.51/1.11)
id AA27077; Fri, 16 May 86 15:40:10 PDT
Date: Fri, 16 May 86 15:40:10 PDT
From: fateman@dali.berkeley.edu (Richard Fateman)
Message-Id: <8605162240.AA27077@dali.berkeley.edu>
To: common-lisp@su-ai.arpa
Subject: coercion of symbols to strings
To convert a symbol to a string one apparently must use the string function.
That is, (coerce 'x 'string) is illegal. But (string 'x) ==> "X" .
Why not allow the former as a synonym for the latter?
∂17-May-86 1200 somewhere!yuasa@kurims.kurims.kyoto-u.junet
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 17 May 86 12:00:25 PDT
Received: by su-shasta.arpa; Sat, 17 May 86 12:00:30 PDT
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA16933; Sat, 17 May 86 14:41:37 jst
From: yuasa@kurims.kurims.kyoto-u.junet
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA16885; Sat, 17 May 86 14:39:17 jst
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA00392; Sat, 17 May 86 13:33:34+0900
Date: Sat, 17 May 86 13:33:34+0900
Message-Id: <8605170433.AA00392@kurims.kyoto-u.junet>
To: common-lisp@su-ai.arpa
I would like to add some keyword parameters to COMPILE in our
Common Lisp system, so that the user can control its behavior
in an implementation-dependent way. However, the specification of
COMPILE in CLtL prevents me from doing this. CLtL says:
compile <name> &optional <definition> [Function]
If <definition> is supplied, it *should* be a lambda-expression,
... If it is not supplied, then <name> should be a symbol ...
The problem arises when the user does not want to specify <definition>, but
does want to specify <name> and implementation-dependent keyword parameters,
since there clearly is no way to do this. There seem to be two solutions
for this problem.
A. Let <definition> be a keyword parameter as in the case of :OUTPUT-FILE
parameter to COMPILE-FILE.
B. Allow COMPILE to accept NIL (or anything other than a lambda-expression)
as the value of <definition>, and let COMPILE work as though no <definition>
was supplied. That is, change the description of COMPILE as:
If <definition> is supplied and is non-NIL, it *should* be ...
... If it is not supplied or if it is NIL, then <name> should be
a symbol ...
B seems more reasonable than A, but A is also acceptable, since, in
my experience, the user seldom wants to supply <definition> actually.
-- Taiichi
∂17-May-86 1218 DCP@ALLEGHENY.SCRC.Symbolics.COM adjusting displaced arrays
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 17 May 86 12:18:33 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17045; Fri 16-May-86 10:27:09-EDT
Date: Fri, 16 May 86 10:22 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: adjusting displaced arrays
To: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]15-May-86 19:26:22.NGALL>
Message-ID: <860516102218.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 15 May 1986 19:26-EDT
From: NGALL@G.BBN.COM
Nit picking.
(DEFUN AREF (ORIGINAL-ARRAY &REST SUBSCRIPTS)
(LABELS ((FOO (ARRAY INDEX)
It would be a tad clearer if FOO were called 1D-AREF
(MULTIPLE-VALUE-BIND (NEW-ARRAY OFFSET) (DISPLACED-ARRAY-P ARRAY)
(IF (NULL NEW-ARRAY)
(ROW-MAJOR-AREF ARRAY INDEX)
ROW-MAJOR-AREF isn't a CL primitive. Our system calls is SYS:%1D-AREF.
It's not clear you need to call it row-major-aref either, as the
row-major part of the computation is dealt with below.
(MULTIPLE-VALUE-CALL #'FOO
You don't need multiple-value-call; FOO takes exactly two arguments.
NEW-ARRAY
(+ INDEX OFFSET)))))
(FOO ORIGINAL-ARRAY
(APPLY #'ARRAY-ROW-MAJOR-INDEX ORIGINAL-ARRAY SUBSCRIPTS))))
I think this is a reasonable extension, but I think it also must warn
users that since arrays are adjustable, and indirect chain can be
changed, and therefore, the target of repeated calls to
DISPLACED-ARRAY-P should not be cached.
∂17-May-86 1724 FAHLMAN@C.CS.CMU.EDU Keyword extensions to Compile
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 May 86 17:24:16 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 17 May 86 20:25:20-EDT
Date: Sat, 17 May 1986 20:25 EDT
Message-ID: <FAHLMAN.12207526395.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Keyword extensions to Compile
In reply to Yuasa:
I agree that it is desirable to allow implementations to add their own
keyword arguments to Compile. It's too bad that we put the Definition
argument in as an optional. Given that it is not used much, it would be
better for it to be a keyword. But we probably should not change this
in an incompatible way now, so your suggestion that we allow NIL to mean
the same thing as not supplying a definition argument is the best
solution, and we might want to make this explicit in the specification
next time around.
However, I think it is legal for you to extend your implementation in
this way as the language is currently defined. It certainly is an error
to supply NIL as the definition argument, since that could not be a
legal definition, so you can define this error case to do something more
useful.
-- Scott
∂18-May-86 0924 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK coercion from X to string
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 18 May 86 09:24:17 PDT
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a012141; 18 May 86 17:18 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Sun, 18 May 86 17:17:59 -0100
Message-Id: <26803.8605181617@aiva.ed.ac.uk>
To: common-lisp@su-ai.arpa
Subject: coercion from X to string
Date: Fri, 16 May 86 15:40:10 PDT
From: Richard Fateman <fateman@edu.berkeley.dali>
Subject: coercion of symbols to strings
To convert a symbol to a string one apparently must use the string function.
That is, (coerce 'x 'string) is illegal. But (string 'x) ==> "X" .
Why not allow the former as a synonym for the latter?
Not only that, (coerce #\a 'string) is an error; you have to use (string #\a).
But for some reason, the powers of 'string' and 'coerce' are reversed for
sequences: 'string' applied to a sequence of characters gives an error,
typically saying the sequence can't be coerced to a string, but 'coerce'
will in fact coerce it. All of this is mentioned in the book (p. 304),
but I found it quite hard to keep it straight at first and had to constantly
refer back to the book.
-- Jeff
∂19-May-86 0918 gls@THINK-AQUINAS.ARPA coercion of symbols to strings
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 19 May 86 09:18:41 PDT
Received: from katherine by Godot.Think.Com via CHAOS; Mon, 19 May 86 12:19:47 edt
Date: Mon, 19 May 86 12:20 EDT
From: Guy Steele <gls@THINK-AQUINAS.ARPA>
Subject: coercion of symbols to strings
To: fateman@dali.berkeley.edu, common-lisp@SU-AI.ARPA
Cc: gls@THINK-AQUINAS.ARPA
In-Reply-To: <8605162240.AA27077@dali.berkeley.edu>
Message-Id: <860519122046.1.GLS@THINK-KATHERINE.ARPA>
Date: Fri, 16 May 86 15:40:10 PDT
From: fateman@dali.berkeley.edu (Richard Fateman)
To convert a symbol to a string one apparently must use the string function.
That is, (coerce 'x 'string) is illegal. But (string 'x) ==> "X" .
Why not allow the former as a synonym for the latter?
Research shows that the Common Lisp archives up to a couple of months
ago contains 18 messages that mention COERCE. None explicitly addresses
this iccue, but the general tone of the messages is one of conservatism.
I now remember that this issue was tied up with the design of the
sequence functions. There was real resistance to letting symbols be
treated as general sequences, and so the general decision was made that
string-specific functions would accept symbols, but general sequence
functions would not. COERCE was limited to performing, for the most part,
sequence coercions and numerical coercions. (As for the latter, there
was an explicit decision not to let COERCE translate between numbers
and characters.)
∂19-May-86 1743 FAHLMAN@C.CS.CMU.EDU coercion of symbols to strings
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 May 86 17:43:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 19 May 86 20:44:18-EDT
Date: Mon, 19 May 1986 20:44 EDT
Message-ID: <FAHLMAN.12208054131.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@AQUINAS.THINK.COM>
Cc: common-lisp@SU-AI.ARPA, fateman@DALI.BERKELEY.EDU
Subject: coercion of symbols to strings
In-reply-to: Msg of 19 May 1986 12:20-EDT from Guy Steele <gls at THINK-AQUINAS.ARPA>
Now that the dust has settled a bit, I would not object to generalizing
coerce to handle some of the additional cases that people imagine it
ought to handle.
-- Scott
∂20-May-86 0022 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU coercion of symbols to strings
Received: from MIT-REAGAN.ARPA by SU-AI.ARPA with TCP; 20 May 86 00:22:33 PDT
Received: from MACH.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 32715; Tue 20-May-86 03:23:37-EDT
Date: Tue, 20 May 86 03:21 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: coercion of symbols to strings
To: fateman@dali.berkeley.edu, common-lisp@SU-AI.ARPA
In-Reply-To: <8605162240.AA27077@dali.berkeley.edu>
Message-ID: <860520032159.3.CFRY@MACH.AI.MIT.EDU>
To convert a symbol to a string one apparently must use the string function.
That is, (coerce 'x 'string) is illegal. But (string 'x) ==> "X" .
Why not allow the former as a synonym for the latter?
Coersion is a powerful, easy to remember concept.
I think it should be extended as much as possible.
The above is reasonable, as are:
(coerce #\a 'string) => "a"
(coerce 123 'string) => "123"
(coerce #\a 'integer) => (char-code #\a) ;this is mentioned as
explicitly not provided CLtL p. 52. It appears that the only reason
is that no one could decide on using char-code or char-int for the conversion
so they chose not to do it at all. This reasoning is odd. Pick the most frequently
used way, document it, and permit it.
Same argument for coercion of numeric types.
Further out extensions might be:
(coerce #'foo 'compiled-function) => returns a compiled function object
we can decide whether or not it should update foo's definition.
(coerce hash-table-1 'list) => makes an list of the values in the hash table.
You can find out their keys via sxhash.
We might also want to convert hash tables to simple-vectors, and visa-versa.
[key on printed representation ?]
(coerce pathname-1 'string)
(coerce string-1 'pathname)
(coerce bit-vector-1 'integer) consider the bit vector to be a
straight binary representation of a non-negative integer.
This is like converting between #*101 and #b101 .
(coerce structure-instance-1 'list)
Coersion between streams and strings sounds useful.
This mechanism could be used to make a string from a file, for example,
or do the reverse.
Undoubtedly there are other coersions which would make sense.
Being implementors, we can think of hairy cases where semantics will
be ambiguous for most of the above suggestions. But typical cases
are, by definition, the cases usually used. The awkward cases can be
documented.
Users would save a lot of manual searching if coerce was extended.
∂20-May-86 0825 fateman%dim@BERKELEY.EDU case using other equality-testing predicates
Received: from UCBVAX.Berkeley.EDU by SU-AI.ARPA with TCP; 20 May 86 08:25:12 PDT
Received: by ucbvax.Berkeley.EDU (5.51/1.13)
id AA03497; Tue, 20 May 86 08:25:15 PDT
Received: by dim (2.0/5.17)
id AA00779; Tue, 20 May 86 08:25:15 pdt
Date: Tue, 20 May 86 08:25:15 pdt
From: fateman%dim@BERKELEY.EDU (Richard Fateman)
Message-Id: <8605201525.AA00779@dim>
To: common-lisp@su-ai.arpa
Subject: case using other equality-testing predicates
If case used equalp or had a keyword :test with the usual meaning,
I could use case instead of redefining it..
I include the explanation below for those who might choose to try to
satisfy my perceived need by another programming construct..
In an application I had hoped to put in a package, I used
a construction analogous to
(in-package 'commandpackage)
.....
(case com ;; com is a command, an atom read in by Lisp reader
(p <some stuff>)
((1 first) <more stuff>)
(cos <yet more stuff>)
... etc)
Now when you read in the atom p, it is not the same as the item
in the case table, which is commandpackage::p. Exporting and then
shadowing-importing p, first, cos, .. is not a good idea, (in general), but
specifically because the symbols first, cos, etc would cover up the
functions of the same name.
What it seems I need is another macro in the case-family that
tests using equalp rather than eql, so I can use strings.. e.g.
(string-case (string com)
("p" <some stuff>)
(("1" "first") <more stuff>)
... etc..
∂20-May-86 1012 DD60@A.CS.CMU.EDU CASE using other equality predicates
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 May 86 10:12:47 PDT
Date: Tue, 20 May 86 13:10 EDT
From: David.Dill@A.CS.CMU.EDU (C410DD60)
To: common-lisp@SU-AI.ARPA
Subject: CASE using other equality predicates
Message-Id: <20May86.131033.DD60@A.CS.CMU.EDU>
While the proposed change might be useful for other reasons, there are a
variety of other solutions to this particular problem. The most obvious
is to call the reader to read the user commands with *package* bound to
the commandpackage package (either explicitly or using IN-PACKAGE), so
that the user commands are interned in the same place as the code.
What I do when I want to be extra careful is put all the commands in
a completely separate package with NO other symbols, export the commands
from that package, explicitly qualify all the commands when I use them
in code (in this example, in the case clauses), and read the symbols
typed by the user into the special command name package.
∂20-May-86 1133 DCP@ALLEGHENY.SCRC.Symbolics.COM case using other equality-testing predicates
Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 20 May 86 11:33:09 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17726; Tue 20-May-86 14:30:15-EDT
Date: Tue, 20 May 86 14:23 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: case using other equality-testing predicates
To: Richard Fateman <fateman%dim@BERKELEY.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <8605201525.AA00779@dim>
Message-ID: <860520142338.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 20 May 86 08:25:15 pdt
From: fateman%dim@BERKELEY.EDU (Richard Fateman)
If case used equalp or had a keyword :test with the usual meaning,
I could use case instead of redefining it..
I include the explanation below for those who might choose to try to
satisfy my perceived need by another programming construct..
For those familiar with the Lisp Machine Lisp-derived dialects,
SELECTQ is pretty much CASE
SELECT is sort-of selectq without the quoting of the items, e.g.,
(select foo
(bar 1)
(baz 2))
==> (COND ((EQL FOO BAR) 1) ((EQL FOO BAZ) 2)) ; BAR and BAZ aren't quoted
SELECTOR is like SELECT (doesn't quote) and gives you the predicate:
(selector foo <
(1 "small")
(q "less than q")
(100 "moderate")
(1000 "big")
(otherwise "huge"))
==> (COND ((< FOO 1) "small")
((< FOO Q) "less than q")
((< FOO 100) "moderate")
((< FOO 1000) "big")
(T "huge"))
Since CLtL doesn't have this functionality, Symbolics has included it in
their extensions. I also note CLtL doesn't have the functionality of
SELECT (which is SELECTOR using EQL), so Symbolics provides that too.
In an application I had hoped to put in a package, I used
a construction analogous to
(in-package 'commandpackage)
.....
(case com ;; com is a command, an atom read in by Lisp reader
(p <some stuff>)
((1 first) <more stuff>)
(cos <yet more stuff>)
... etc)
Now when you read in the atom p, it is not the same as the item
in the case table, which is commandpackage::p. Exporting and then
shadowing-importing p, first, cos, .. is not a good idea, (in general), but
specifically because the symbols first, cos, etc would cover up the
functions of the same name.
What it seems I need is another macro in the case-family that
tests using equalp rather than eql, so I can use strings.. e.g.
(string-case (string com)
("p" <some stuff>)
(("1" "first") <more stuff>)
... etc..
∂20-May-86 1302 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM case using other equality-testing predicates
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 20 May 86 13:02:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4184; Tue 20-May-86 15:38:12 EDT
Date: Tue, 20 May 86 15:35 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: case using other equality-testing predicates
To: fateman%dim@UCB-VAX.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8605201525.AA00779@dim>
Message-ID: <860520153533.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Regardless of whether your particular application does or does not need
it, I too have long wanted to be able to specify the test function in
CASE. In Symbolics Common Lisp we have this as an alternate function
name. I'm sure some people will jump all over me for suggesting this,
but it might be better to allow CASE to accept a :TEST keyword. Which
of these three syntaxes do you-all prefer?
(selector item equalp ("foo" ...) ...)
(case item :test #'equalp ("foo" ...) ...)
(cond ((equalp item "foo") ...) ...)
∂20-May-86 1418 KMP@SCRC-STONY-BROOK.ARPA Keyword extensions to Compile
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 May 86 14:18:10 PDT
Received: from HUMMINGBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 3157; Tue 20-May-86 17:15:51 EDT
Date: Tue, 20 May 86 17:16 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Keyword extensions to Compile
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12207526395.BABYL@C.CS.CMU.EDU>
Message-ID: <860520171605.2.KMP@HUMMINGBIRD.SCRC.Symbolics.COM>
Date: Sat, 17 May 1986 20:25 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
... I think it is legal for you to extend your implementation in
this way as the language is currently defined ...
Let's stop talking "legal" for a while and talk "rational".
There are lots of gaping holes in the language and it's one thing to agree
that a Common Lisp which is "suspect" is technically correct because the
manual doesn't contradict them. It's another thing altogether to suggest
that implementations not yet written should be encouraged to be as loose
with the wording.
We want to be tolerant of those who took the manual at face value as a spec
they could implement faithfully and be proud of, but we also want to keep
in mind that there's much which we've learned since creating that spec and
it would be silly not to encourage people to use this new knowledge when
designing new CL systems.
It continues to amaze me that people have made "upward-compatible"
extensions to the core language. This just makes it hard to debug
portable programs. CLtL has primitives built in which allow extensions
to be made in a non-intrusive way and I think everyone should use
those in their implementation and leave the standard language alone.
Put another way, I think that every implementation should pick some other
package and put all their extensions on that package and leave the LISP
package pure. We've hashed this one out at length. If someone doesn't
think that there was overwhelming concensus that this was the right
thing, I'd like to hear from them.
VAXLISP, to pick an example at random, does not currently do this.
They throw lots of symbols in with the standard LISP package. I hope
they have plans to change that. Symbolics almost does it right by
having an SCL package for its extensions, but still doesn't go all the
way by shadowing the symbols in LISP which it intends to extend
incompatibly. I'm trying to get that changed.
My recommendation to anyone who wants to extend COMPILE (or any other
function)'s argument specs would be to simply shadow COMPILE on another
package, FOO, and do
(DEFUN LISP:COMPILE (NAME &OPTIONAL DEFINITION)
(FOO:COMPILE NAME DEFINITION))
This way, callers of LISP:COMPILE cannot possibly get non-standard features
in code that's intended to be portable. People who know about the extensions
can also know what package they need to use in order to make the extensions
available. Life becomes much simpler that way.
The problem with making upward compatible extensions is that someone might
accidentally use them and not remember the fact. They'd typically get no
diagnostics from their compiler -- in the case of functions (especially
in light of APPLY or the ability to have a variable evaluate to a keyword),
it's not possible to detect all such uses at compile time. The result is that
the first time they find out they're losing is when they port to another
dialect and it rejects the extended argument syntax. ... if they're lucky.
If they're not lucky, it doesn't reject the syntax. Maybe it thinks it
understands the extended syntax -- and if it thinks it does, maybe it's
right -- then again, maybe it's not. Maybe you eventually get an error
signalled -- or maybe you just get the wrong answer.
I'm not just making this problem up. It has already really happened to me
in real-live attempts to port things. It is a royal pain to debug. If we
don't take steps to alleviate it, we're doing users a disservice.
I've spent some time in-house talking to our software support staff about
problems they're going to come up against when dealing with CL customers
and the worst one is going to be the fact that customers using CL are going
to expect that porting CL code should be a breeze and are going to be quite
surprised at the difficulties they can encounter. In my opinion, that's
a fault of CL, not a fault of Symbolics or DEC or Lucid or whomever. In
the long run, every vendor is going to have some set of users who are upset
at the vendor because their program "which ran fine in some other implementation"
doesn't work in the new implementation. More often than not, it's going to
really be due to the fact that the "other implementation" was too forgiving
and let them run non-portable code. My experience says that the user will
blame the vendor who gave them the new, more restrictive implementation
for their headaches, not the one that let them run the bogus code in the
first place. If it's any vendor's fault that lossage arises, it's probably
the less restrictive implementation, not the more restrictive one. But
I don't think it's any vendor's fault at all. It isn't fair for the
individual vendors to take this heat because they've had no advice about
how to avoid this problem, or even that it's a problem to be avoided.
The fault belongs to the designers. It's time we started asking serious
questions about what portability is really about, and giving good advice
about how implementors should proceed in the future before.
Again, I'm not talking about declaring existing implementations to be "wrong".
I'm just talking about laying down guidelines for how people can and should
build better implementations in the future. For now it's just friendly advice.
Nothing legalistic involved... yet. That advice -should- be part of a later
spec, I think, and implementations which claimed to adhere to that revised
spec and still didn't heed that advice would at that time be declared to be
in error.
∂20-May-86 1806 Gregor.pa@Xerox.COM Re: Keyword extensions to Compile
Received: from XEROX.COM by SU-AI.ARPA with TCP; 20 May 86 17:42:40 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 MAY 86 17:20:30 PDT
Date: 20 May 86 17:20 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Keyword extensions to Compile
In-reply-to: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>'s message of Tue,
20 May 86 17:16 EDT
To: KMP@SCRC-STONY-BROOK.arpa
cc: Fahlman@C.CS.CMU.EDU, common-lisp@su-ai.arpa
Message-ID: <860520-172030-1065@Xerox>
Kent is right. These kinds of extensions are definitely responsible for
a large number of porting problems.
In addition to having all their extensions in another package, a quality
implementation may want to consider using warnings to identify things
that aren't real common-lisp. This would help someone prepare their
code for porting.
Gregor
∂20-May-86 2009 Gregor.pa@Xerox.COM Re: Keyword extensions to Compile
Received: from XEROX.COM by SU-AI.ARPA with TCP; 20 May 86 17:42:40 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 MAY 86 17:20:30 PDT
Date: 20 May 86 17:20 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Keyword extensions to Compile
In-reply-to: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>'s message of Tue,
20 May 86 17:16 EDT
To: KMP@SCRC-STONY-BROOK.arpa
cc: Fahlman@C.CS.CMU.EDU, common-lisp@su-ai.arpa
Message-ID: <860520-172030-1065@Xerox>
Kent is right. These kinds of extensions are definitely responsible for
a large number of porting problems.
In addition to having all their extensions in another package, a quality
implementation may want to consider using warnings to identify things
that aren't real common-lisp. This would help someone prepare their
code for porting.
Gregor
∂20-May-86 2036 FAHLMAN@C.CS.CMU.EDU Keyword extensions to Compile
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 May 86 20:36:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 20 May 86 23:35:34-EDT
Date: Tue, 20 May 1986 23:35 EDT
Message-ID: <FAHLMAN.12208347447.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Keyword extensions to Compile
In-reply-to: Msg of 20 May 1986 17:16-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Since day one we have emphasized that, while Common Lisp should be a
perfectly usable language in its own right, many implementations would
be supersets of Common Lisp. That was an essential part of the original
treaty. The participation of Symbolics, in particular, was absolutely
conditional on this point of view, since many beloved Lisp Machine
features (beloved by Symbolics people at the time, anyway) obviously
made no sense in a language that also had to be implemented on stock
hardware. For many years, Symbolics people made a fetish of always
referring to "the Common Lisp subset" rather than just "Common Lisp",
though that seems to have gone away.
For implementation X to be a superset of Common Lisp means that Common
Lisp programs written according to the manual will run in X, but that
many legal programs in implementation X will not be portable Common Lisp
and will not necessarily run in implementation Y. Or, put another way,
you make a superset by taking various cases that are errors in vanilla
Common Lisp and by giving them useful interpretations in your superset.
This is usually done with undefined functions, but it can also be done
by adding new keywords to old functions or by extending type-specific
functions to take new types of arguments that would otherwise be in
error. There is some controversy over whether it is allowable to extend
an implementation by returning extra values from built-in functions; I
favor allowing this, but it is possible (not natural, but possible) to
write legal Common Lisp code that would be screwed by this.
I think that we should require an implementation to document any such
extensions, and encourage implementors to provide a "portable" compiler
mode that flags any use of non-standard extensions. But to outlaw
extensions at this late date is impossible. I agree that it would be a
good idea in an implementation to have a package (not necessarily the
LISP package) in which nothing but pure Common Lisp is visible. I think
we can encourage this, but I'm not sure about requiring it.
Put another way, I think that every implementation should pick some other
package and put all their extensions on that package and leave the LISP
package pure. We've hashed this one out at length. If someone doesn't
think that there was overwhelming concensus that this was the right
thing, I'd like to hear from them.
I don't think that consensus was reached on this. There was mail on
both sides, and in the absence of a decision procedure, the discussion
eventually petered out. This will certainly be among the issues we want
to get a final decision on as the ANSI spec is developed.
Since you ask, my own view is (still) that each implementation will want
to provide a default Lisp environment for their users, including all of
Common Lisp plus some implementation-specific extensions, and that this
is what should live in the LISP package and be inherited by default in
other packages such as USER. It is certainly a good idea to have some
other package that is pure Common Lisp, but this should not be the
default environment for users. The mix of things in the default
environment should be a local option.
-- Scott
∂20-May-86 2046 FAHLMAN@C.CS.CMU.EDU case using other equality-testing predicates
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 May 86 20:46:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 20 May 86 23:45:35-EDT
Date: Tue, 20 May 1986 23:45 EDT
Message-ID: <FAHLMAN.12208349281.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: case using other equality-testing predicates
In-reply-to: Msg of 20 May 1986 15:35-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
I'm sure some people will jump all over me for suggesting this,
but it might be better to allow CASE to accept a :TEST keyword. Which
of these three syntaxes do you-all prefer?
(selector item equalp ("foo" ...) ...)
(case item :test #'equalp ("foo" ...) ...)
(cond ((equalp item "foo") ...) ...)
I think that mixing keywords into a construct like Case that already has
a complex syntax is likely to cause confusion. I would prefer adding a
new construct CASE-TEST that would look like
(case-test #'equalp item ("foo" ...) ...)
This is similar to your Selector, but without the odd treatment of the
test function, and the name emphasizes the close parallel to Case. I
think it is best to put the test function before the item -- other
things in the language put the testing function first.
-- Scott
∂20-May-86 2110 DT50@A.CS.CMU.EDU case-test
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 May 86 21:10:12 PDT
Date: 21 May 86 00:09 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
To: common-lisp@SU-AI.ARPA
Subject: case-test
CC: fahlman@C.CS.CMU.EDU
I like the idea of CASE-TEST, but not the name.
Wouldn't CASE-IF be closer to the other things in the language that take
predicate first arguments (such as REMOVE-IF, FIND-IF, etc.)? I can't think
of any other Common Lisp function that ends in -TEST.
-- Dave
∂20-May-86 2123 FAHLMAN@C.CS.CMU.EDU case-test
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 May 86 21:21:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 21 May 86 00:20:52-EDT
Date: Wed, 21 May 1986 00:20 EDT
Message-ID: <FAHLMAN.12208355701.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dave.Touretzky@A.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: case-test
In-reply-to: Msg of 21 May 1986 00:09-EDT from Dave.Touretzky at A.CS.CMU.EDU
Wouldn't CASE-IF be closer to the other things in the language that take
predicate first arguments (such as REMOVE-IF, FIND-IF, etc.)? I can't think
of any other Common Lisp function that ends in -TEST.
I thought about that, but I believe that the "if" forms all take unary
predicates at present.
-- Scott
∂20-May-86 2304 ELIOT%umass-cs.csnet@CSNET-RELAY.ARPA Coerce (Symbols)
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 20 May 86 22:57:03 PDT
Received: from umass-cs by csnet-relay.csnet id av02545; 21 May 86 1:33 EDT
Date: Tue, 20 May 86 15:31 EST
From: ELIOT%umass-cs.csnet@CSNET-RELAY.ARPA
To: common-lisp@SU-AI.ARPA
Subject: Coerce (Symbols)
Coercing symbols to strings is fine, as long as NIL is treated as
the empty SEQUENCE, rather than as a symbol.
I have also wanted to have an :initial-contents argument to make-string
and make-sequence, analogous to make-array. (Make-list should also
have an :initial-contents arg.)
∂21-May-86 1025 snyder%hplsny@hplabs.ARPA Re: Keyword extensions to Compile
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 21 May 86 10:25:03 PDT
Received: from hplsny by hplabs.ARPA ; Wed, 21 May 86 10:23:16 pdt
Received: by hplsny ; Wed, 21 May 86 10:23:15 pdt
From: Alan Snyder <snyder%hplsny@hplabs.ARPA>
Message-Id: <8605211723.AA03797@hplsny>
Date: Wednesday, May 21, 1986 10:23:11
Subject: Re: Keyword extensions to Compile
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 20-May-86 23:35:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
For implementation X to be a superset of Common Lisp means that Common
Lisp programs written according to the manual will run in X ...
you make a superset by taking various cases that are errors in vanilla
Common Lisp and by giving them useful interpretations in your superset.
This is usually done with undefined functions, ...
Since you ask, my own view is (still) that each implementation will want
to provide a default Lisp environment for their users, including all of
Common Lisp plus some implementation-specific extensions, and that this
is what should live in the LISP package and be inherited by default in
other packages such as USER.
Common Lisp programs written "according to the manual" may fail to run in a
supserset implementation under your proposal if they define packages that
inherit from the LISP package (the default case) and the LISP package contains
extra, unexpected symbols (because of package conflicts, unintended function
redefinition, etc.).
Alan
-------
∂21-May-86 1230 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM case using other equality-testing predicates
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 21 May 86 12:30:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5442; Wed 21-May-86 14:17:26 EDT
Date: Wed, 21 May 86 14:14 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: case using other equality-testing predicates
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12208349281.BABYL@C.CS.CMU.EDU>
Message-ID: <860521141451.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 20 May 1986 23:45 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I'm sure some people will jump all over me for suggesting this,
but it might be better to allow CASE to accept a :TEST keyword. Which
of these three syntaxes do you-all prefer?
(selector item equalp ("foo" ...) ...)
(case item :test #'equalp ("foo" ...) ...)
(cond ((equalp item "foo") ...) ...)
I think that mixing keywords into a construct like Case that already has
a complex syntax is likely to cause confusion.
I agree. But the other alternatives cause confusion, too.
I would prefer adding a
new construct CASE-TEST that would look like
(case-test #'equalp item ("foo" ...) ...)
This is similar to your Selector, but without the odd treatment of the
test function, and the name emphasizes the close parallel to Case. I
think it is best to put the test function before the item -- other
things in the language put the testing function first.
So where would additional options, such as :KEY and an option that
controls whether or not the keys at the heads of the clauses are
evaluated, go in your syntax?
I guess it's obvious why Common Lisp doesn't currently have a way to do this
-- no one has thought of a syntax for it that anyone else likes.
∂21-May-86 1252 REM@IMSSS Mismatch between name of function and what it really does
Date: 1986 May 19 09:34:14 PST (=GMT-8hr)
From: Robert Elton Maas <REM%IMSSS@SU-AI.ARPA>
To:gls@THINK-AQUINAS.ARPA
CC:MATHIS@USC-ISIF.ARPA,COMMON-LISP@SU-AI.ARPA
Subject:Mismatch between name of function and what it really does
G> Date: Mon, 19 May 86 12:20 EDT
G> From: Guy Steele <gls@THINK-AQUINAS.ARPA>
G> Subject: coercion of symbols to strings
(Re allowing (COERCE 'X 'STRING) to coerce X to the string "X")
G> ..., and so the general decision was made that
G> string-specific functions would accept symbols, but general sequence
G> functions would not. COERCE was limited to performing, for the most part,
G> sequence coercions and numerical coercions.
This is one of the bad points (in my opinion) of many LISPs, including
CL, functions that are mis-named or otherwise don't do what you'd
except from their name. Examples:
INTERN doesn't internalize things any more, it does something
different which I don't understand (why not use a different name?)
COERCE works only for sequences and numbers, not for arbitrary things
that can obviously be coerced. For the latter you have to use
various other functions whose names you have to individually remember.
NTH may return a tail or the CAR of a tail, may take the list or the
index as first argument, and may take the index starting at 0 or at
1, in various LISPs, and having used several I can never remember
which it is currently this year (why not do what I do, name this and
related functions more explicitly: NTHCDR-LN0 NTHC-LN0 NTHCDR-N0L
NTHC-N0L NTHCDR-LN1 NTHC-LN1 NTHCDR-N1L NTHC-N1L for the 8 possible
variants, each of which is optimal for certain applications?).
I hope (my opinion, of course) the international standards committee
will fix this kind of problem so programmers reading somebody else's
code can have the meaning apparent in most cases from general
programming tradition rather than having to constantly check the
manual to see if the function does what it seems to say it would do.
∂21-May-86 1315 Bobrow.pa@Xerox.COM Re: case using other equality-testing predicates
Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 May 86 13:15:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAY 86 11:40:43 PDT
Date: 21 May 86 10:51 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: case using other equality-testing predicates
In-reply-to: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>'s message of
Tue, 20 May 86 15:35 EDT
To: Moon@SCRC-STONY-BROOK.ARPA
cc: fateman%dim@UCBVAX.Berkeley.EDU, common-lisp@SU-AI.ARPA
From: Bobrow.pa@Xerox.COM (Danny Bobrow)
Message-ID: <860521-114043-168@Xerox>
>> ...to be able to specify the test function in CASE.
>> (selector item equalp ("foo" ...) ...)
>>
>> (case item :test #'equalp ("foo" ...) ...)
>>
>> (cond ((equalp item "foo") ...) ...)
Of the three, I prefer the
(case item :test #'equalp ("foo" ...) ...)
But I would rather a separate function
(case-with-test item equalp ...)
----- dgb:
∂21-May-86 1316 Gregor.pa@Xerox.COM Re: Keyword extensions to Compile
Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 May 86 13:15:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAY 86 12:57:56 PDT
Date: 21 May 86 11:40 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Keyword extensions to Compile
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Tue,
20 May 86 23:35 EDT
To: Fahlman@C.CS.CMU.EDU
cc: KMP@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.arpa
Message-ID: <860521-125756-1077@Xerox>
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Keyword extensions to Compile
I don't think that consensus was reached on this. There was mail on
both sides, and in the absence of a decision procedure, the discussion
eventually petered out. This will certainly be among the issues we want
to get a final decision on as the ANSI spec is developed.
I don't recall any argument that other than "it might be nice for users
of that implementation" that suggested that implementations should
be allowed to put extra symbols in the lisp package. I believe that
Kent and I made strong cases for not doing this based on the kinds of
problems it has caused us both. The point is a portable program needs
to know what it is going to get when it says (make-package 'foo), an
implementation-specific program can know that it will get extra nice
stuff if it says (make-package 'foo :use 'extended-common-lisp), but a
portable program needs to be able to protect itself from that extra stuff.
∂21-May-86 1344 FAHLMAN@C.CS.CMU.EDU Keyword extensions to Compile
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 May 86 13:44:30 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 21 May 86 16:43:25-EDT
Date: Wed, 21 May 1986 16:43 EDT
Message-ID: <FAHLMAN.12208534526.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gregor.pa@XEROX.COM
Cc: common-lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
Subject: Keyword extensions to Compile
In-reply-to: Msg of 21 May 1986 14:40-EDT from Gregor.pa at Xerox.COM
The point is a portable program needs
to know what it is going to get when it says (make-package 'foo), an
implementation-specific program can know that it will get extra nice
stuff if it says (make-package 'foo :use 'extended-common-lisp), but a
portable program needs to be able to protect itself from that extra stuff.
Or alternatively, the portable package could say (make-package 'foo :use
'pure-common-lisp) while random users say (make-package 'foo).
I guess if we want to get serious about portable code, we're going to
have to require that implementations provide a pure Common Lisp package,
even though this will be pretty bloody for implementations that didn't
start off this way. Then all we've got to argue about is whether the
pure or extended version gets the name "LISP", and with it the default
inclusion into other packages. This is not a life-or-death issue with
me, but I think that getting the extended stuff by default is the right
way to go.
-- Scott
∂21-May-86 1346 DCP@SAPSUCKER.SCRC.Symbolics.COM Coerce (Symbols)
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 21 May 86 13:46:16 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 22528; Wed 21-May-86 16:41:19 EDT
Date: Wed, 21 May 86 16:45 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Coerce (Symbols)
To: ELIOT%umass-cs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 20 May 86 16:31 EDT from ELIOT%umass-cs.csnet@CSNET-RELAY.ARPA
Message-ID: <860521164558.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 20 May 86 15:31 EST
From: ELIOT%umass-cs.csnet@CSNET-RELAY.ARPA
Coercing symbols to strings is fine, as long as NIL is treated as
the empty SEQUENCE, rather than as a symbol.
I have also wanted to have an :initial-contents argument to make-string
and make-sequence, analogous to make-array. (Make-list should also
have an :initial-contents arg.)
Does (coerce <symbol> 'string) return
(symbol-name <symbol>), or
(format nil "~S" <symbol>), which would (possibly) include the package, or
(format nil "~A::~A"
(package-name (symbol-package <symbol>))
(symbol-name <symbol>))
or what? If this weren't enough, added in with my personal views of
style and functionality, for me to want to help veto this coersion, the
special casing of NIL certainly would. Programs should reflect their
meaning. A string is a sequence, a symbol is not. Why shouldn't
(coerce :ascii-EOT 'integer)
work? The answer is that the requested behavior is not a coersion
between compatible types, it is a functional translation between human
understandable names for the ascii control characters and the integers
that are their corresponding values.
∂21-May-86 1357 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Porting Cl code
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 21 May 86 13:56:40 PDT
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a000698; 21 May 86 18:11 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Wed, 21 May 86 17:04:43 -0100
Message-Id: <9828.8605211604@aiva.ed.ac.uk>
To: Fahlman@c.cs.cmu.edu, KMP@scrc-stony-brook.arpa
Subject: Porting Cl code
Cc: common-lisp@su-ai.arpa, eulisp%inria.uucp@Cs.Ucl.AC.UK
Date: Tue, 20 May 86 17:16 EDT
From: Kent M Pitman <KMP@arpa.scrc-stony-brook>
Subject: Keyword extensions to Compile
Let's stop talking "legal" for a while and talk "rational".
...
I've spent some time in-house talking to our software support staff about
problems they're going to come up against when dealing with CL customers
and the worst one is going to be the fact that customers using CL are going
to expect that porting CL code should be a breeze and are going to be quite
surprised at the difficulties they can encounter. In my opinion, that's
a fault of CL, not a fault of Symbolics or DEC or Lucid or whomever.
...
I fully agree with everything Kent said in his message, and in particular that
(1) implementations should package extensions so that they do not make visible
changes in the basic language, (2) stricter implementations are better in that
code written for them will be more portable, and (3) portability problems are
often due to looseness in the specification.
(Consider, for example, compiling. CLtL says very little about the compiler
and refers to most uses of EVAL-WHEN as "esoteric". There is little to guide
a user (or implementor) who is not already familiar with a similar system, and
implementations of CL differ on default "eval-when times". IN KCL, for
example, everything seems to be eval-compile-load, so it is very easy to write
programs that run interpreted and compile in KCL but do not compile in, say,
Lucid.)
One of the most common criticisms of Common Lisp that I hear, and such
criticism may be more common now in Europe than in the US, is that it is not
really a language but a collection of languages, and that it takes work to
port programs from one dialect to another. In a sense, the whole point to
Common Lisp is to make porting easier; we should do everything we can to make
it so.
-- Jeff
∂21-May-86 1406 hpfclp!diamant@hplabs.ARPA Re: Keyword extensions to Compile
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 21 May 86 14:05:33 PDT
Received: by hplabs.ARPA ; Wed, 21 May 86 14:03:49 pdt
Date: Wed, 21 May 86 14:03:49 pdt
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: Re: Keyword extensions to Compile
From: "Scott E. Fahlman" <hplabs!Fahlman@C.CS.CMU.EDU>
Put another way, I think that every implementation should pick some other
package and put all their extensions on that package and leave the LISP
package pure. We've hashed this one out at length. If someone doesn't
think that there was overwhelming concensus that this was the right
thing, I'd like to hear from them.
I don't think that consensus was reached on this. There was mail on
both sides, and in the absence of a decision procedure, the discussion
eventually petered out. This will certainly be among the issues we want
to get a final decision on as the ANSI spec is developed.
Since you ask, my own view is (still) that each implementation will want
to provide a default Lisp environment for their users, including all of
Common Lisp plus some implementation-specific extensions, and that this
is what should live in the LISP package and be inherited by default in
other packages such as USER. It is certainly a good idea to have some
other package that is pure Common Lisp, but this should not be the
default environment for users. The mix of things in the default
environment should be a local option.
-- Scott
The problem with making the default environment the extended one is that it
is IMPOSSIBLE to write portable programs! If implementation X makes an
incompatible extension to COMPILE, and I want the CL-only environment so
I can use the CLtL version of COMPILE, I must say something like:
#+X (progn
(unuse-package 'lisp)
(use-package 'cl-only)) ; or some other non-standard package name
I realize that someday we may agree on the name of the this other package, but
that isn't an upward compatible change. It requires everyone trying to write
portable code based on the first edition of CLtL to change their code. The
piece of code above has made the inherently portable program no longer
portable (since if I didn't know about implementation X, I couldn't have
written it to run on implementation X).
If, on the other hand, the lisp package (and the default environment) contained
no extensions, you wouldn't need to say anything for portable programs, and
for programs specific to that environment, you would say:
#+X (use-package 'extensions) ; or whatever it is called.
It is much preferable to require the use of *features* in inherently
non-portable code than in portable code that has been made non-portable because
the Lisp system comes up in a non-portable mode.
John Diamant
∂21-May-86 1406 BSG@SCRC-STONY-BROOK.ARPA case using other equality-testing predicates
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 21 May 86 14:06:28 PDT
Received: from SORA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 4186; Wed 21-May-86 17:08:11 EDT
Date: Wed, 21 May 86 17:05 EDT
From: Bernard S. Greenberg <BSG@SCRC-STONY-BROOK.ARPA>
Subject: case using other equality-testing predicates
To: Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860521141451.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860521170559.1.BSG@SORA.SCRC.Symbolics.COM>
Date: Wed, 21 May 86 14:14 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: Tue, 20 May 1986 23:45 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I'm sure some people will jump all over me for suggesting this,
but it might be better to allow CASE to accept a :TEST keyword. Which
of these three syntaxes do you-all prefer?
(selector item equalp ("foo" ...) ...)
(case item :test #'equalp ("foo" ...) ...)
(cond ((equalp item "foo") ...) ...)
I think that mixing keywords into a construct like Case that already has
a complex syntax is likely to cause confusion.
I agree. But the other alternatives cause confusion, too.
I would prefer adding a
new construct CASE-TEST that would look like
(case-test #'equalp item ("foo" ...) ...)
This is similar to your Selector, but without the odd treatment of the
test function, and the name emphasizes the close parallel to Case. I
think it is best to put the test function before the item -- other
things in the language put the testing function first.
So where would additional options, such as :KEY and an option that
controls whether or not the keys at the heads of the clauses are
evaluated, go in your syntax?
I guess it's obvious why Common Lisp doesn't currently have a way to do this
-- no one has thought of a syntax for it that anyone else likes.
(seleckter object (:key -- :test ---)
("foo" ...
∂21-May-86 1526 JAR@AI.AI.MIT.EDU Keyword extensions to Compile
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 21 May 86 15:25:25 PDT
Date: Wed, 21 May 86 17:50:46 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Keyword extensions to Compile
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA, Gregor.pa@XEROX.COM,
KMP@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Wed 21 May 1986 16:43 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[AI.AI.MIT.EDU].44171.860521.JAR>
Date: Wed, 21 May 1986 16:43 EDT
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
I guess if we want to get serious about portable code, we're going to
have to require that implementations provide a pure Common Lisp package,
even though this will be pretty bloody for implementations that didn't
start off this way. Then all we've got to argue about is whether the
pure or extended version gets the name "LISP", and with it the default
inclusion into other packages. This is not a life-or-death issue with
me, but I think that getting the extended stuff by default is the right
way to go.
I also agree with what Kent and Gregor have said on this topic. I'm
not sure I understand why anyone bothered inventing Common Lisp in the
first place if we weren't serious about portability. I think this is
a very important question. I get the impression that very few people
out there have tried moving real programs from one Common Lisp
implementation to another. One thing that makes this situation
particularly bad is that people who are closest to the implementations
themselves, and are in a position to make life easier for those of us
trying to write portable code, are exactly those people LEAST likely
to need to transport code, so I don't believe their motivation to make
portability really work is very high. Chances are good that they
don't even use other implementations besides their own. I don't
perceive market demands here, either (yet), which would be another
motivation to clean this up. So right now a small number of us just
have to suffer.
I don't think we need to go to the Ada extreme, but there is a lot
to be said for it. The current state of affairs is quite
unsatisfactory.
Jonathan
∂21-May-86 1606 Gregor.pa@Xerox.COM Re: case using other equality-testing predicates
Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 May 86 16:06:10 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 21 MAY 86 16:05:38 PDT
Date: 21 May 86 16:03 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: case using other equality-testing predicates
In-reply-to: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>'s message of
Wed, 21 May 86 14:14 EDT
To: Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.arpa
Message-ID: <860521-160538-1375@Xerox>
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: case using other equality-testing predicates
So where would additional options, such as :KEY and an option that
controls whether or not the keys at the heads of the clauses are
evaluated, go in your syntax?
Do we really need additional options? Its easy to get the behavior of
a :key option in the obvious way, after all:
(ncase (car item) #'eq
(a (do-a))
(b (do-b))
(otherwise (lose)))
is at least as clear as:
(ncase item
(:test #'eq :key #'car)
(a (do-a))
(b (do-b))
(otherwise (lose)))
or something, and since none of the other case macros make it possible
to evaluate the "keys at the heads of the clauses" I am not sure why
this one should.
∂21-May-86 1752 DCP@SAPSUCKER.SCRC.Symbolics.COM Re: case using other equality-testing predicates
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 21 May 86 17:51:48 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 22684; Wed 21-May-86 20:46:37 EDT
Date: Wed, 21 May 86 20:51 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Re: case using other equality-testing predicates
To: Gregor.pa@Xerox.COM, Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860521-160538-1375@Xerox>
Message-ID: <860521205110.7.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 21 May 86 16:03 PDT
From: Gregor.pa@Xerox.COM
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: case using other equality-testing predicates
So where would additional options, such as :KEY and an option that
controls whether or not the keys at the heads of the clauses are
evaluated, go in your syntax?
Do we really need additional options? Its easy to get the behavior of
a :key option in the obvious way, after all:
(ncase (car item) #'eq
(a (do-a))
(b (do-b))
(otherwise (lose)))
is at least as clear as:
(ncase item
(:test #'eq :key #'car)
(a (do-a))
(b (do-b))
(otherwise (lose)))
or something, and since none of the other case macros make it possible
to evaluate the "keys at the heads of the clauses" I am not sure why
this one should.
[I'm not wedded to the name selector.]
Symbols (the normal thing case gets used for) aren't evaluated because
that is the normal thing for case. Consider my original example again:
(selector foo <
(1 "small")
(10 "moderate")
(q "less than q")
(1000 "big")
(otherwise "huge"))
This can't be done unless Q gets evaluated because the test isn't EQL
but something arbitrary.
I'll warn the community of some rather strange looking code this can
sometimes produce:
- If you want to use EQUAL on a list, you need to do something like
(selector foo equal
(('(1 2 3) ...whatever...)))
because
(selector foo equal
('(1 2 3) ...whatever...))
is realy
(selector foo equal
((quote (1 2 3)) ...whatever...))
=> (cond ((or (equal foo quote)
(equal foo (1 2 3)))
...whatever...))
which is not what was intended. Maybe the implicit OR clause shouldn't
be included?
∂21-May-86 2039 Hvatum.DLAB@MIT-MULTICS.ARPA (see below)
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 21 May 86 20:39:19 PDT
Date: Wed, 21 May 86 23:31 EDT
From: Hvatum@MIT-MULTICS.ARPA
Subject: (see below)
To: common-lisp@SU-AI.ARPA
Message-ID: <860522033136.597246@MIT-MULTICS.ARPA>
To: Common-Lisp
From: Stephen Bacher at Draper Lab
Subject: Lexical references in DEFMACRO - reply to a previous message from
Dave Moon
> I think if you actually write out the seemingly obvious defmacro, you
> will see that it's not so:
>
> (defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) unique-id))))
>
> which does not reference unique-id as a variable from the body of
> the macro, only from the expansion of the macro.
>
I don't see what Dave Moon is trying to accomplish here. The point of
the discussion is whether you can reference lexical variables in the
expansion function, not in the expanded body - of course you can't
reference the lexical variable in the expanded code! So, if DEFMACRO
uses a null lexical environment, you can't reference UNIQUE-ID, and if
it doesn't, you can, and the appropriate macro definition to test this
should be:
(defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) ',unique-id)))
==================================================================
MC.LCS.MIT.EDU is flakey. We may have missed mail that would make
the above comment moot. Please remove KSH@MC.LCS.MIT.EDU from
the Common-Lisp distribution and add Hvatum@MULTICS.MIT.EDU
instead. Thanks.
==================================================================≠
∂22-May-86 0002 somewhere!yuasa@kurims.kurims.kyoto-u.junet
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 22 May 86 00:01:16 PDT
Received: by su-shasta.arpa; Wed, 21 May 86 23:59:58 PDT
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA12294; Thu, 22 May 86 13:33:33 jst
From: yuasa@kurims.kurims.kyoto-u.junet
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA12254; Thu, 22 May 86 13:32:27 jst
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA00603; Thu, 22 May 86 12:44:25+0900
Date: Thu, 22 May 86 12:44:25+0900
Message-Id: <8605220344.AA00603@kurims.kyoto-u.junet>
To: common-lisp@su-ai.arpa
Having heard of the problems on the LISP package extensions,
I got tempted to add the following constant into our system.
THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE [Constant]
The value of this constant is a list of those symbols that are added in
the LISP package by the implementation. An external symbol in the LISP
package must be either the one specified in CLtL or an element of this
list, may not be both. It is expected that the value of this constant
be NIL.
(The name does not matter.)
With this constant, implementors of portable code could do the shadowing
easily.
(SHADOW THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE)
I know this would not solve all the problem, but it is better than nothing.
At least, Gregor's PCL code might become clearer, if all CL implementations
support this kind of constant. Any comments?
-- Taiichi
∂22-May-86 0806 preece%ccvaxa@gswd-vms.ARPA Re: Keyword extensions to Compile
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 22 May 86 08:06:35 PDT
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/)
id AA00104; Thu, 22 May 86 10:05:49 CDT
Message-Id: <8605221505.AA00104@gswd-vms.ARPA>
Date: Thu, 22 May 86 09:17:06 cdt
From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: Keyword extensions to Compile
> From: hpfclp!diamant@hplabs.ARPA
> The problem with making the default environment the extended one is
> that it is IMPOSSIBLE to write portable programs! If implementation X
> makes an incompatible extension to COMPILE, and I want the CL-only
> environment so I can use the CLtL version of COMPILE, I must say
> something like: #+X (progn (unuse-package 'lisp) (use-package
> 'cl-only)) ; or some other non-standard package name
----------
You're combining the important objection to "some other non-standard
package name" with the objection to the default environment. They're
separate issues. I think the name of the pure CL package should be
standard (probably it should be lisp), but I think the default
environment should be the local environment, including appropriate
enhancements, and portable code should back off to the standard
pure-CL package. I don't want users to have to specify their
environment at startup, even in a canned initialization file. The
default environment should be what corresponds to our implementation-
specific users' guide.
But the name of the pure-CL package should obviously be standardized.
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
∂22-May-86 0959 KMP@SCRC-STONY-BROOK.ARPA Further remarks about portability
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 86 09:58:30 PDT
Received: from HUMMINGBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 5065; Thu 22-May-86 13:00:03 EDT
Date: Thu, 22 May 86 12:56 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Further remarks about portability
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <8605220344.AA00603@kurims.kyoto-u.junet>,
The message of 21 May 86 14:03-PDT from hpfclp!diamant@hplabs.ARPA,
<8605211723.AA03797@hplsny>
Message-ID: <860522125620.8.KMP@HUMMINGBIRD.SCRC.Symbolics.COM>
This message contains replies to and remarks about several of the messages
which have crossed the list since my message a couple of days ago...
Date: Thu, 22 May 86 12:44:25+0900
From: yuasa@kurims.kurims.kyoto-u.junet
Having heard of the problems on the LISP package extensions, I got
tempted to add the following constant into our system.
THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE [Constant]
... (The name does not matter.) With this constant, implementors of
portable code could do the shadowing easily.
(SHADOW THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE)
I know this would not solve all the problem, but it is better than nothing.
At least, Gregor's PCL code might become clearer, if all CL implementations
support this kind of constant. Any comments?
If you implement such a thing without the rest of us standardizing on it, it's
of little value since portable code won't know to look for it. I mention this
only because you sounded like your message sounds like you're looking for an
interim solution.
Also, -all- portable programs would have to begin with:
(SHADOW THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE)
because they wouldn't stand a real chance of running correctly without it. This
seems a little silly since the point of CL was not to agree on a package that was
incompatible and then to patch it with a way to get around that agreed-upon
incompatibility. The point of CL was to give users who cared about portability
something they could cling to so they don't get swept away by the whims of
designers of specific implementations. If we don't give people at least that,
we're not doing very much for them.
I think it was Jonathan Rees who pointed out that the problem is more severe
because the home package of a symbol severely affects the portability of code
which has been read by READ and printed by PRINT in a given implementation.
This problem fails to be addressed by your shadow technique. Consider the
following program:
(IN-PACKAGE 'PROCESSOR)
(USE-PACKAGE 'LISP)
(SHADOW THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE)
(DEFUN PROCESS-FILE (INPUT-FILE OUTPUT-FILE)
(LET ((*PACKAGE* (FIND-PACKAGE "PROCESSOR")))
(WITH-OPEN-FILE (INPUT-STREAM INPUT-FILE :DIRECTION :INPUT)
(WITH-OPEN-FILE (OUTPUT-STREAM OUTPUT-FILE :DIRECTION :OUTPUT)
(PRINT (READ INPUT-STREAM) OUTPUT-STREAM)))))
and a file A.LISP which contains the expression:
(FOO LISP:FOO)
If (PROCESS-FILE "A.LISP" "B.LISP") is done, then B.LISP is not portable if
the LISP package can vary its contents because the output may contain either
(FOO LISP:FOO) or (FOO FOO) depending upon whether FOO was on the LISP package
and therefore got shadowed in this implementation. In another implementation,
different results will be produced. If the results of such processing are
shared back and forth between different implementations (as I could easily
imagine wanting to happen in Macsyma's save files, for example), the results
could be disastrous.
Finally, I'd like to remark that I couldn't help getting a chuckle out of
the following message from John Diamant. He's obviously in agreement with me
on this, but unfortunately (as I've learned the hard way), the full magnitude
of the problem is worse than he describes it...
Date: Wed, 21 May 86 14:03:49 pdt
From: hpfclp!diamant@hplabs.ARPA
... The problem with making the default environment the extended one is that it
is IMPOSSIBLE to write portable programs! If implementation X makes an
incompatible extension to COMPILE, and I want the CL-only environment so
I can use the CLtL version of COMPILE, I must say something like:
#+X (progn
(unuse-package 'lisp)
(use-package 'cl-only)) ; or some other non-standard package name
I realize that someday we may agree on the name of the this other package, but
that isn't an upward compatible change. It requires everyone trying to write
portable code based on the first edition of CLtL to change their code. The
piece of code above has made the inherently portable program no longer
portable (since if I didn't know about implementation X, I couldn't have
written it to run on implementation X).
Not only is all this too true, but even worse, we don't even require
implementations to put any distinguishing feature in their implementation. Eg,
VAXLISP 1.2 comes up with a features list that includes things like VAX, VMS,
etc. but nothing that says DIGITAL or DEC or anything. The result is that if I
knew someone else (eg, LUCID) had implemented a lisp that ran under VAX VMS,
I'd not be able to tell from the features list whose Lisp I was running under.
To further aggravate things, we don't specify what package things in the
features list should be in, so while on the LispM you do
(PUSH ':FOO LISP:*FEATURES*) and later #+FOO in any package works, in VAXLISP
you have to do (PUSH 'WHATEVER:FOO LISP:*FEATURES*) and #+FOO only works in
the WHATEVER package. (I assume #+WHATEVER:FOO works elsewhere but have never
actually constructed the test. Perhaps I shouldn't be so sure, though, since
#+3600 and #-3600 don't do the obvious thing -- they both get read errors.
No reason they shouldn't since CLtL doesn't say they'll work.)
My point is that we failed to standardize just enough even on #+ and #- so that
it's hard even when you've bitten the bullet and decided to just write
implementation specific code in some places. This is a terrible shame. In
retrospect, I think that if there's one thing we should have gotten right in
the first release of CL, it was #+ and #- so that people would have a foothold
when other things didn't work.
Right along side that should have been to make the LISP package contain all and
only the things mentioned in CLtL. There just isn't a substitute for this.
Anything less just screws those people who care about portability.
It's silly to say that there shouldn't be a standard package which contains
only CL stuff because allowing that to happen lets open the situation where I
could create a system which took all symbols having n letters or less which
were not defined in CLtL and defined them to be system constants that couldn't
be assigned, bound, etc. and which had completely silly values. Would we want
to admit that such a language was a Common Lisp? Fahlman is arguing that we
should.
It's also silly to say that the point of CL was to define a lot of interesting
meanings but finally not to put them in some known place, which is effectively
what Fahlman is suggesting.
I'm not trying to cast blame on anyone about past decisions. Most of us had the
power to speak up early on and failed to notice the impending problem. As they say,
hindsight is always 20/20. If we made mistakes, they were arguably not intentional.
CL is obviously a highly ambitious experiment in portability. There were so many
things to deal with the first time around that it wasn't possible to know what was
going to matter in the end. But now we're at the crossroads to the future with
time our side and better access to experience and knowledge than we had the last
time around. If we make any new CL spec and it doesn't correct these problems,
lack of proper experience and time isn't going to be so good a defense. Users are
going to think that either we don't care about portability or that we don't
understand it. I don't know which I think would be worse.
∂22-May-86 1614 hpfclp!diamant@hplabs.ARPA Re: Keyword extensions to Compile
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 22 May 86 15:56:11 PDT
Received: by hplabs.ARPA ; Thu, 22 May 86 15:54:14 pdt
Date: Thu, 22 May 86 15:54:14 pdt
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: Re: Keyword extensions to Compile
From: hplabs!preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
> From: hpfclp!diamant@hplabs.ARPA
> The problem with making the default environment the extended one is
> that it is IMPOSSIBLE to write portable programs! If implementation X
> makes an incompatible extension to COMPILE, and I want the CL-only
> environment so I can use the CLtL version of COMPILE, I must say
> something like: #+X (progn (unuse-package 'lisp) (use-package
> 'cl-only)) ; or some other non-standard package name
----------
You're combining the important objection to "some other non-standard
package name" with the objection to the default environment. They're
separate issues. I think the name of the pure CL package should be
standard (probably it should be lisp), but I think the default
It is at least as important that the extended environment has a standard name,
or you can't turn it off portably, if it is on by default. Sure, you can
create your own package and explicitly use the pure package, but you can't
unuse the extended package from the USER package unless its name is
standardized.
environment should be the local environment, including appropriate
enhancements, and portable code should back off to the standard
pure-CL package. I don't want users to have to specify their
environment at startup, even in a canned initialization file. The
default environment should be what corresponds to our implementation-
specific users' guide.
I was aware that I was discussing both issues, but I apologize if it
was unclear from my comments above. Let me explain why I consider these
related. I believe that we should make the ANSI standard upward compatible
where possible with CLtL. This requires that the pure Common Lisp package
be called LISP. Since CLtL also says that the default environment uses LISP
(MAKE-PACKAGE states this explicitly), and that the USER package uses LISP,
again the only way to make an upward compatible extension is to leave this
alone, and use another mechanism to get full-blown environment (such as a
global flag which is off by default). Otherwise, people who have written
"portable" programs based on CLtL will have to change them (in a portable way)
to work on ANSI standard Common Lisp. It is true, I am more concerned about
there being a pure lisp package, and its being called LISP, than about the
default environment. My earlier objection about the impossibility of writing
portable programs hinges on the name of the extended package being
non-standard, and I see general agreement here that we must standardize that
name. My concern about the default environment is based on upward
compatibility, and my concern about standardization of the name was to make
sure that it was still possible to write portable programs.
But the name of the pure-CL package should obviously be standardized.
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
My proposal is that we define a function with a standard name that tells
MAKE-PACKAGE et. al. (and sets the values for the USER package) whether to
go by CLtL or to include the extensions package, which by then will have
a standard name. So you would say something like:
(SET-DEFAULT-ENVIRONMENT 'LISP) ; for bare CLtL
or
(SET-DEFAULT-ENVIRONMENT 'EXTENSIONS) ; for the extended environment
This would not only set the global flag, but change the use list of USER to
contain the package specified instead of whichever one it had. This has to
be a function instead of a variable, because it must actively change the use
list of the USER package. I would still prefer that this would be set to
LISP by default so that programs which are now portable don't need to change
when the ANSI standard comes out, but this way each user can set up (say in
an init file) his preference for getting a portable environment, or a "full"
environment.
Notice that this scheme has the added advantage of allowing the user to
specify an arbitrary default environment (he can make a package with any
mix of LISP, EXTENSIONS, or whatever -- even merge extensions from multiple
Lisps, if the source is available to him.
By the way, regarding the home package problem that KMP mentions, we need to
require that the home package of the symbols exported from the LISP package
(the pure one) are homed in the LISP package.
John Diamant
Systems Software Operation UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant
Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs
Fort Collins, CO
∂22-May-86 1925 FAHLMAN@C.CS.CMU.EDU Where Pure Common Lisp lives
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 May 86 19:24:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 22 May 86 22:24:17-EDT
Date: Thu, 22 May 1986 22:24 EDT
Message-ID: <FAHLMAN.12208858771.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Where Pure Common Lisp lives
OK, having been beaten soundly by everyone who has ever tried to port a
big program, I'm ready to agree that the path of maximum sanity is to
require that the LISP package contain only the symbols of pure Common
Lisp, and that we create a new standard package (I like the name
"LOCAL") for containing the local lisp environment, with possible
extensions. I'd like to see some variable that holds the current
default package for MAKE-PACKAGE, with the default default being LISP.
We should encourage implementations (maybe require, but I'm not sure
about this) not to extend the language by adding keywords and other
non-standard options to the functions in LISP, but to put such
extensions in LOCAL instead.
Once we start considering exactly what goes into the ANSI/ISO spec (I'll
be sending a message about this soon, probably over the weekend), I'll
propose this for formal consideration.
-- Scott
∂23-May-86 0507 DCP@SAPSUCKER.SCRC.Symbolics.COM Where Pure Common Lisp lives
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 23 May 86 05:07:27 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23010; Fri 23-May-86 08:02:40 EDT
Date: Fri, 23 May 86 08:06 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Where Pure Common Lisp lives
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12208858771.BABYL@C.CS.CMU.EDU>
Message-ID: <860523080646.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
A nit pick on names: LOCAL is poor. What does LOCAL: mean to somebody
in California (pick a site) running an implementation developed in the
eastern US (pick a site)? VENDOR-EXTENSIONS: is more meaningful than
LOCAL:. SYMBOLICS-COMMON-LISP: (SCL:) is >much< more meaningful than
LOCAL:. I guess my question is: What is gained by agreeing on the
standard package for extensions. I know this came up 6 weeks ago, but I
don't think the issue was closed.
∂23-May-86 0703 preece%ccvaxa@gswd-vms.ARPA Re: Where Pure Common Lisp lives
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 23 May 86 07:02:55 PDT
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/)
id AA00943; Fri, 23 May 86 09:01:50 CDT
Message-Id: <8605231401.AA00943@gswd-vms.ARPA>
Date: Fri, 23 May 86 08:59:07 cdt
From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: Where Pure Common Lisp lives
> From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
>
> A nit pick on names: LOCAL is poor.
----------
I agree. LOCAL is a good name for site-local stuff, not for
vendor-specific stuff. The name of the local extensions
package probably ought to be the name of the implementation,
possibly subdivided if the vendor supports multiple
implmentations. Thus DEC ought to have a VAXLISP package
and separate VAXLISP-ULTRIX and VAXLISP-VMS packages for
OS-specific features [not picking on DEC -- they just came
to mind as a vendor with multiple sub-implementations].
The default environment should be the most specific one; in
the example case it should be LOCAL, which is on top of
VAXLISP-ULTRIX, which is on top of VAXLISP, which is on top
of LISP. Sites would normally, though, establish their own
defaults at installation.
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
∂23-May-86 0735 FAHLMAN@C.CS.CMU.EDU Where Pure Common Lisp lives
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 May 86 07:34:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 23 May 86 10:33:49-EDT
Date: Fri, 23 May 1986 10:33 EDT
Message-ID: <FAHLMAN.12208991565.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: COMMON-LISP@SU-AI.ARPA
Subject: Where Pure Common Lisp lives
In-reply-to: Msg of 23 May 1986 09:59-EDT from preece%ccvaxa at gswd-vms.ARPA (Scott E. Preece)
I'm not wedded to the name "LOCAL", but if the place you go to get the
default good environment on your machine is not "LISP", it has to be
some standard package name. Maybe "EXTENDED", or whatever. This could
be set up as a nickname for "SCL" or "DEC'S-PROPRIETARY-VAX-EXTENSIONS"
or whatever, but it should be a uniform place on each machien so users
don't have to hunt for it.
-- Scott
∂23-May-86 0755 franz!fimass!jkf@kim.Berkeley.EDU list of lisp package external symbols
Received: from [128.32.130.7] by SU-AI.ARPA with TCP; 23 May 86 07:54:52 PDT
Received: by kim.Berkeley.EDU (5.51/1.12)
id AA21757; Fri, 23 May 86 07:54:40 PDT
Received: from fimass by franz (5.5/3.14)
id AA09972; Fri, 23 May 86 06:52:14 PDT
Received: by fimass (5.5/3.14)
id AA04561; Fri, 23 May 86 05:50:48 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Return-Path: <fimass!jkf>
Message-Id: <8605231350.AA04561@fimass>
To: common-lisp@su-ai.arpa
Subject: list of lisp package external symbols
Date: Fri, 23 May 86 05:50:43 PST
Is there an official 'online' list of the external lisp package
symbols implied by the Common Lisp book? If not, I'd like to
start the process of computing the list by supplying the following
list which I believe to be very close to correct. Are there any
additions or deletions?
--- start list
&allow-other-keys &aux &body &environment &key &optional &rest &whole *
** *** *applyhook* *break-on-warnings* *debug-io*
*default-pathname-defaults* *error-output* *evalhook* *features*
*load-verbose* *macroexpand-hook* *modules* *package* *print-array*
*print-base* *print-case* *print-circle* *print-escape* *print-gensym*
*print-length* *print-level* *print-pretty* *print-radix* *query-io*
*random-state* *read-base* *read-default-float-format* *read-suppress*
*readtable* *standard-input* *standard-output* *terminal-io*
*trace-output* + ++ +++ - / // /// /= 1+ 1- < <= = > >= abs acons acos
acosh adjoin adjust-array adjustable-array-p alpha-char-p alphanumericp
and append apply applyhook apropos apropos-list aref array
array-dimension array-dimension-limit array-dimensions
array-element-type array-has-fill-pointer-p array-in-bounds-p
array-rank array-rank-limit array-row-major-index array-total-size
array-total-size-limit arrayp ash asin asinh assert assoc assoc-if
assoc-if-not atan atanh atom bignum bit bit-and bit-andc1 bit-andc2
bit-eqv bit-ior bit-nand bit-nor bit-not bit-orc1 bit-orc2 bit-vector
bit-vector-p bit-xor block boole boole-1 boole-2 boole-and boole-andc1
boole-andc2 boole-c1 boole-c2 boole-clr boole-eqv boole-ior boole-nand
boole-nor boole-orc1 boole-orc2 boole-set boole-xor both-case-p boundp
break butlast byte byte-position byte-size caaaar caaadr caaar caadar
caaddr caadr caar cadaar cadadr cadar caddar cadddr caddr cadr
call-arguments-limit car case catch ccase cdaaar cdaadr cdaar cdadar
cdaddr cdadr cdar cddaar cddadr cddar cdddar cddddr cdddr cddr cdr
ceiling cerror char char-bit char-bits char-bits-limit char-code
char-code-limit char-control-bit char-downcase char-equal char-font
char-font-limit char-greaterp char-hyper-bit char-int char-lessp
char-meta-bit char-name char-not-equal char-not-greaterp char-not-lessp
char-super-bit char-upcase char/= char< char<= char= char> char>=
character characterp check-type cis clear-input clear-output close
clrhash code-char coerce common commonp
compile compile-file compiled-function compiled-function-p compiler-let
complex complexp concatenate cond conjugate cons consp constantp
copy-alist copy-list copy-readtable copy-seq copy-symbol copy-tree cos
cosh count count-if count-if-not ctypecase decf declaration declare
decode-float decode-universal-time defconstant define-modify-macro
define-setf-method defmacro defparameter defsetf defstruct deftype
defun defvar delete delete-duplicates delete-file delete-if
delete-if-not denominator deposit-field describe digit-char
digit-char-p directory directory-namestring disassemble do do*
do-all-symbols do-external-symbols do-symbols documentation dolist
dotimes double-float double-float-epsilon double-float-negative-epsilon
dpb dribble ecase ed eighth elt encode-universal-time endp
enough-namestring eq eql equal equalp error etypecase eval eval-when
evalhook evenp every exp export expt fboundp fceiling ffloor fifth
file-author file-length file-namestring file-position file-write-date
fill fill-pointer find find-all-symbols find-if find-if-not
find-package find-symbol finish-output first fixnum flet float
float-digits float-precision float-radix float-sign floatp floor
fmakunbound force-output format fourth fresh-line fround ftruncate
ftype funcall function functionp gcd gensym gentemp get
get-decoded-time get-dispatch-macro-character get-internal-real-time
get-internal-run-time get-macro-character get-output-stream-string
get-properties get-setf-method get-setf-method-multiple-value
get-universal-time getf gethash go graphic-char-p
hash-table hash-table-count hash-table-p host-namestring identity if
ignore imagpart import in-package incf inline input-stream-p inspect
int-char integer integer-decode-float integer-length integerp intern
internal-time-units-per-second intersection isqrt keyword keywordp
labels lambda lambda-list-keywords lambda-parameters-limit last lcm ldb
ldb-test ldiff least-negative-double-float least-negative-long-float
least-negative-short-float least-negative-single-float
least-positive-double-float least-positive-long-float
least-positive-short-float least-positive-single-float length let let*
lisp-implementation-type lisp-implementation-version list list*
list-all-packages list-length listen listp load locally log logand
logandc1 logandc2 logbitp logcount logeqv logior lognand lognor lognot
logorc1 logorc2 logtest logxor long-float long-float-epsilon
long-float-negative-epsilon long-site-name loop lower-case-p
machine-instance machine-type machine-version macro-function
macroexpand macroexpand-1 macrolet make-array make-broadcast-stream
make-char make-concatenated-stream make-dispatch-macro-character
make-echo-stream make-hash-table make-list make-package make-pathname
make-random-state make-sequence make-string make-string-input-stream
make-string-output-stream make-symbol make-synonym-stream
make-two-way-stream makunbound map mapc mapcan mapcar mapcon maphash
mapl maplist mask-field max member member-if member-if-not merge
merge-pathnames min minusp mismatch mod most-negative-double-float
most-negative-fixnum most-negative-long-float most-negative-short-float
most-negative-single-float most-positive-double-float
most-positive-fixnum most-positive-long-float most-positive-short-float
most-positive-single-float multiple-value-bind multiple-value-call
multiple-value-list multiple-value-prog1 multiple-value-setq
multiple-values-limit name-char namestring nbutlast nconc nil
nintersection ninth not notany notevery notinline nreconc nreverse
nset-difference nset-exclusive-or nstring-capitalize nstring-downcase
nstring-upcase nsublis nsubst nsubst-if nsubst-if-not nsubstitute
nsubstitute-if nsubstitute-if-not nth nthcdr null number numberp
numerator nunion oddp open optimize or otherwise output-stream-p
package package-name package-nicknames package-shadowing-symbols
package-use-list package-used-by-list packagep pairlis parse-integer
parse-namestring pathname pathname-device pathname-directory
pathname-host pathname-name pathname-type pathname-version pathnamep
peek-char phase pi plusp pop position position-if position-if-not
pprint prin1 prin1-to-string princ princ-to-string print probe-file
proclaim prog prog* prog1 prog2 progn progv provide psetf psetq push
pushnew quote random random-state random-state-p rassoc rassoc-if
rassoc-if-not ratio rational rationalize rationalp read read-byte
read-char read-char-no-hang read-delimited-list read-from-string
read-line read-preserving-whitespace readtable readtablep realpart
reduce rem remf remhash remove remove-duplicates remove-if
remove-if-not remprop rename-file rename-package replace require rest
return return-from revappend reverse room rotatef round rplaca rplacd
safety satisfies sbit scale-float schar search second sequence
sequencep set set-char-bit set-difference set-dispatch-macro-character
set-exclusive-or set-macro-character set-syntax-from-char setf setq
seventh shadow shadowing-import shiftf short-float short-float-epsilon
short-float-negative-epsilon short-site-name signed-byte signum
simple-array simple-bit-vector simple-bit-vector-p simple-string
simple-string-p simple-vector simple-vector-p sin single-float
single-float-epsilon single-float-negative-epsilon sinh sixth sleep
software-type software-version some sort space special special-form-p
speed sqrt stable-sort standard-char standard-char-p step stream
stream-element-type streamp string string-capitalize string-char
string-char-p string-downcase string-equal string-greaterp
string-left-trim string-lessp string-not-equal string-not-greaterp
string-not-lessp string-right-trim
string-trim string-upcase string/= string< string<= string= string>
string>= stringp structure sublis subseq subsetp subst subst-if
subst-if-not substitute substitute-if substitute-if-not subtypep svref
sxhash symbol symbol-function symbol-name symbol-package symbol-plist
symbol-value symbolp t tagbody tailp tan tanh tenth terpri the third
throw time trace tree-equal truename truncate type type-of typecase
typep unexport unintern union unless unread-char unsigned-byte untrace
unuse-package unwind-protect upper-case-p use-package
user-homedir-pathname values values-list variable vector vector-pop
vector-push vector-push-extend vectorp warn when with-input-from-string
with-open-file with-open-stream with-output-to-string write write-byte
write-char write-line write-string write-to-string y-or-n-p yes-or-no-p
zerop
---- end-list
John Foderaro
Franz Inc.
∂23-May-86 0834 SOLEY@XX.LCS.MIT.EDU Where Pure Common Lisp lives
Received: from XX.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 May 86 08:34:01 PDT
Date: Fri, 23 May 1986 11:32 EDT
Message-ID: <SOLEY.12209002314.BABYL@XX.LCS.MIT.EDU>
From: SOLEY@XX.LCS.MIT.EDU
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Where Pure Common Lisp lives
In-reply-to: Msg of 23 May 1986 10:33-EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Date: Friday, 23 May 1986 10:33-EDT
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Sender: FAHLMAN at C.CS.CMU.EDU
To: COMMON-LISP at SU-AI.ARPA
Re: Where Pure Common Lisp lives
I'm not wedded to the name "LOCAL", but if the place you go to get the
default good environment on your machine is not "LISP", it has to be
some standard package name.
Actually, I agree more with Plummer - the EXTENDED package you mention
will probably offer a totally different environment in each CL
implementation. You DO want your user to hunt for it (i.e., look in
the doc), since the coincidence of the name might make the user
believe that the same interfaces are offered in each CL.
This is just the naming problem on a grander scale, offerred up
because of the global namespace of package names. If I write an FFT
package and DCP does too, and we both call the package FFT, and the
interfaces (functions) in the packages are different, that's a bug,
not a feature.
-- Richard
∂23-May-86 0846 snyder%hplsny@hplabs.ARPA Re: Where Pure Common Lisp lives
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 23 May 86 08:45:58 PDT
Received: from hplsny by hplabs.ARPA ; Fri, 23 May 86 08:44:06 pdt
Received: by hplsny ; Fri, 23 May 86 08:43:56 pdt
From: Alan Snyder <snyder%hplsny@hplabs.ARPA>
Message-Id: <8605231543.AA00822@hplsny>
Date: Friday, May 23, 1986 08:43:52
Subject: Re: Where Pure Common Lisp lives
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 22-May-86 22:24:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
OK, having been beaten soundly by everyone who has ever tried to port a
big program, I'm ready to agree that the path of maximum sanity is to
require that the LISP package contain only the symbols of pure Common
Lisp, and that we create a new standard package (I like the name
"LOCAL") for containing the local lisp environment, with possible
extensions. I'd like to see some variable that holds the current
default package for MAKE-PACKAGE, with the default default being LISP.
I feel very uneasy about introducing a global variable that controls the
behavior of MAKE-PACKAGE. How can I expect portable code to load correctly
if this variable has any value other than LISP?
Here's an alternative: How about leaving LISP:MAKE-PACKAGE alone, and defining
LOCAL:MAKE-PACKAGE to default to the LOCAL package?
Alan
-------
∂23-May-86 0858 KMP@SCRC-STONY-BROOK.ARPA LISP:*LOCAL-PACKAGE*
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 May 86 08:58:09 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 6049; Fri 23-May-86 11:59:40 EDT
Date: Fri, 23 May 86 11:56 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: LISP:*LOCAL-PACKAGE*
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
In-Reply-To: <FAHLMAN.12208858771.BABYL@C.CS.CMU.EDU>
Message-ID: <860523115607.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 22 May 1986 22:24 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
... I'm ready to agree that the path of maximum sanity is to require
that the LISP package contain only the symbols of pure Common Lisp,
and that we create a new standard package (I like the name "LOCAL")
for containing the local lisp environment, with possible extensions.
I think we should agree to disagree on naming anything that is implementation
specific. If two implementations have a LOCAL:FOO function and they don't do
the same thing, it will be hard to detect the problem until runtime. Again,
the absence of VAXLISP:FOO in the Symbolics environment or the absence of
SYMBOLICS:FOO in VAXLISP will be easy to detect. After all, to use the
implementation stuff, people will have to have read the implementation-specific
manual, which will tell them the package name.
Also, and importantly, I can create a VAXLISP:FOO if I need it on a 3600 in
order to not have to edit the source file containing the reference. If both
implementations call their extension LOCAL:FOO, the fix is not so easy to make
because some other code I'm using may already reference Symbolics' LOCAL:FOO
and may not be happy if I bash that definition with something to make some ported
VAXLISP code happy.
I'd like to see some variable that holds the current default package for
MAKE-PACKAGE, with the default default being LISP.
As long as a portable program can specify LISP explicitly and not have to worry
that this variable will override that, I'm agreeable to that. In fact, I don't
see the use of it, though, unless you allow the default default to vary from
implementation to implementation. In other words, I think it's fine for programs
that don't say they want LISP to get whatever they get -- all my programs will
say LISP so they'll not be bothered by this feature. You might as well let VAXLISP
make this variable be #<Package "VAXLISP"> and Symbolics let this package be
#<Package "SCL">, etc. I'll call this variable *LOCAL-PACKAGE* for purposes of
discussion here; I'm not wedded to the name -- another possibility might be
*NATIVE-PACKAGE*.
We should encourage implementations (maybe require, but I'm not sure
about this) not to extend the language by adding keywords and other
non-standard options to the functions in LISP, but to put such
extensions in LOCAL instead.
I agree, but rather than "LOCAL" the value of *LOCAL-PACKAGE*.
Once we start considering exactly what goes into the ANSI/ISO spec (I'll
be sending a message about this soon, probably over the weekend), I'll
propose this for formal consideration.
OK. This is starting to sound pretty good. Based on your message and the
others that have gone by, what would make me happy would be...
LISP - a pure CL package to make the hard-core portability folks happy.
LISP:*LOCAL-PACKAGE* - a variable holding the a package which is named
(hopefully uniquely) in a system-dependent way by each implementation.
This should use LISP. There's a minor issue about whether this should
be a system constant (no stars) or a settable variable. I'm not fussy.
USER - a package which uses LISP and which uses the package which is the
value of LISP:*LOCAL-PACKAGE* .
MAKE-PACKAGE,etc - as before, but if no package is explicitly given to
use, the default would be LISP:*LOCAL-PACKAGE* . Writers of most portable
code would use LISP explicitly.
At this point, I'll back off a little and admit that some classes of portable
code will usefully be able to take advantage of LISP:*LOCAL-PACKAGE* . Portable
programs can't be coded in an environment where the local package is active
because the author won't know what the program will mean in an arbitrarily
mucked up environment. Macsyma is a good example of this kind of program.
But some portable programs, though written in a portable subset, might want to
be able to portably extend whatever environment was available on the local
machine. An example of this might be GLISP. I would expect such a program to
be written in some package (GLISP-INTERNALS, I guess) which used only LISP,
but which sometimes manipulated LISP:*LOCAL-PACKAGE* -- particularly for the
purpose of creating a GLISP package based on LISP:*LOCAL-PACKAGE*. Code written
in such a GLISP package might not be portable even though it could built by
a portable program. (I'm kinda handwaving the GLISP example here because I'm
not familiar with its details; if my example doesn't hold up, perhaps you can
go back and re-cast this paragraph using AMORD or FRL or some other layered
language as an example with better results).
Thoughts, anyone?
∂23-May-86 1114 Moon@SCRC-QUABBIN.ARPA Where Pure Common Lisp lives
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 23 May 86 11:00:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 1566; Fri 23-May-86 13:59:52 EDT
Date: Fri, 23 May 86 13:55 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Where Pure Common Lisp lives
To: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12208991565.BABYL@C.CS.CMU.EDU>
Message-ID: <860523135545.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 23 May 1986 10:33 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I'm not wedded to the name "LOCAL", but if the place you go to get the
default good environment on your machine is not "LISP", it has to be
some standard package name. Maybe "EXTENDED", or whatever. This could
be set up as a nickname for "SCL" or "DEC'S-PROPRIETARY-VAX-EXTENSIONS"
or whatever, but it should be a uniform place on each machien so users
don't have to hunt for it.
If you want to make a package that uses the same exported symbols as the
user package, you do (MAKE-PACKAGE "MY-VERY-OWN-PACKAGE"
:USE (PACKAGE-USE-LIST (PACKAGE "USER"))).
I don't see any reason why we need to add a new language feature that
duplicates this. I agree completely with the people who say that the default
for :USE in MAKE-PACKAGE should be the portable default, not the full
local extensions.
∂23-May-86 1152 greek%bach.decnet@hudson.dec.com Scott's comments on extensions
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 May 86 11:45:28 PDT
Date: 23 May 86 14:45:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Scott's comments on extensions
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I hope we'll all read Scott's comments carefully and give them the
attention they deserve. I have a related question.
Let's say in VAX LISP we have a LISP package with pure Common LISP and
a VAXLISP package with our extensions. Which packages should the
USER package use?
Unfortunately, certain answers to that question will be incompatible
with our situation now, where everything is in the LISP package.
- Paul
------
∂23-May-86 1206 FAHLMAN@C.CS.CMU.EDU Where Pure Common Lisp lives
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 May 86 11:59:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 23 May 86 14:57:58-EDT
Date: Fri, 23 May 1986 14:57 EDT
Message-ID: <FAHLMAN.12209039656.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Where Pure Common Lisp lives
In-reply-to: Msg of 23 May 1986 13:55-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
If you want to make a package that uses the same exported symbols as the
user package, you do (MAKE-PACKAGE "MY-VERY-OWN-PACKAGE"
:USE (PACKAGE-USE-LIST (PACKAGE "USER"))).
I don't see any reason why we need to add a new language feature that
duplicates this. I agree completely with the people who say that the default
for :USE in MAKE-PACKAGE should be the portable default, not the full
local extensions.
Hmmmm...is USER allowed to start up with random local extensions in it,
or is it supposed to inherit ONLY from the LISP package, which is now
pure Common Lisp? How have people been reading this? Part of my
objection to making LISP pure was because I assumed that this meant USER
had to be pure as well, which means that we need another standard place
to look for the default local environment.
-- Scott
∂23-May-86 1233 greek%bach.decnet@hudson.dec.com Momentary disengagement of brain.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 May 86 12:27:02 PDT
Date: 23 May 86 15:19:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Momentary disengagement of brain.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Sorry, I was referring to Kent's comments, not Scott's.
- Paul
------
∂23-May-86 1234 DSinger@SRI-KL.ARPA Pure CL, package names etc.
Received: from SRI-KL.ARPA by SU-AI.ARPA with TCP; 23 May 86 12:31:05 PDT
Date: Fri 23 May 86 09:38:03-PDT
From: David Singer <DSinger@SRI-KL>
Subject: Pure CL, package names etc.
To: common-lisp%SU-AI@SRI-KL
I don't think the vendor extended package on different vendors systems
should have the same name, because the won't have the same meaning (i.e.
contents). The pure CL package should be called LISP; portable programs
are well advised to select it explicitly; any other extensions should be
in packages which are functionally named as far as possible, and inherited
(maybe) by packages like SYMBOLICS-COMMON-LISP et al. so that there is
a single 'extended' package on each machine. Many of the extensions can
be and will be at least semi-portable, or from other than the original
lisp vendor. To the largest extent possible these extensions should be
functionally separated into packages with functional names, rather than
names which signify nothing (e.g. EXTENDED) or the vendor name. I would
expect sites, under such a scheme, to develop their extended package(s)
to suit them, knowing that if they import e.g. LISP and TENSOR-ALGEBRA
they'll either get pure cl+tensors or an error.
Dave Singer
-------
∂23-May-86 1253 snyder%hplsny@hplabs.ARPA Re: Scott's comments on extensions
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 23 May 86 12:52:00 PDT
Received: from hplsny by hplabs.ARPA ; Fri, 23 May 86 12:49:26 pdt
Received: by hplsny ; Fri, 23 May 86 12:49:16 pdt
From: Alan Snyder <snyder%hplsny@hplabs.ARPA>
Message-Id: <8605231949.AA01057@hplsny>
Date: Friday, May 23, 1986 12:49:12
Subject: Re: Scott's comments on extensions
To: greek%bach.decnet@hudson.dec.com
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 23-May-86 14:45:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Let's say in VAX LISP we have a LISP package with pure Common LISP and
a VAXLISP package with our extensions. Which packages should the
USER package use?
My model is that portable code will always define its own package, i.e., it
will not live in the USER package. The USER package is where you type in
commands and test expressions and perhaps build prototypes. Therefore, I
don't think the language definition particularly needs to constrain what
packages the USER package uses. In your case, I would guess that users would
prefer that it use both LISP and VAXLISP (I'm reading your statement to mean
that VAXLISP exports ONLY your extensions).
The situation becomes interesting if there are conflicts between LISP and
VAXLISP (which I would expect, if VAXLISP extends the definitions of LISP
functions). In this case, I think users would want VAXLISP to use LISP and
export all of its non-shadowed symbols; then the USER package would use only
VAXLISP.
Alan
-------
∂23-May-86 1802 Hornig@ELEPHANT-BUTTE.SCRC.Symbolics.COM list of lisp package external symbols
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 23 May 86 18:01:45 PDT
Received: from HOME.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7384; Fri 23-May-86 17:35:30 EDT
Date: Fri, 23 May 86 17:34 EDT
From: Charles Hornig <Hornig@SCRC-RIVERSIDE.ARPA>
Subject: list of lisp package external symbols
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8605231350.AA04561@fimass>
Message-ID: <860523173447.2.HORNIG@HOME.SCRC.Symbolics.COM>
Date: Fri, 23 May 86 05:50:43 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Is there an official 'online' list of the external lisp package
symbols implied by the Common Lisp book? If not, I'd like to
start the process of computing the list by supplying the following
list which I believe to be very close to correct. Are there any
additions or deletions?
...list removed...
I would add COMPILATION-SPEED and remove SEQUENCEP.
∂23-May-86 1814 @SCRC-QUABBIN.ARPA,@EUPHRATES.SCRC.Symbolics.COM:Moon@SCRC-STONY-BROOK.ARPA Where Pure Common Lisp lives
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 23 May 86 18:13:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via INTERNET with SMTP id 1816; 23 May 86 20:56:24 EDT
Date: Fri, 23 May 86 20:54 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Where Pure Common Lisp lives
To: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12209039656.BABYL@C.CS.CMU.EDU>
Message-ID: <860523205433.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 23 May 1986 14:57 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Hmmmm...is USER allowed to start up with random local extensions in it,
or is it supposed to inherit ONLY from the LISP package, which is now
pure Common Lisp? How have people been reading this? Part of my
objection to making LISP pure was because I assumed that this meant USER
had to be pure as well, which means that we need another standard place
to look for the default local environment.
I always assumed USER was supposed to have everything in it. I guess this
is not written down anyplace, though. Sigh.
To be a true standard to which many implementations adhere, rather than the
original goal of making four Lisp implementations go in the same direction
instead of four different directions, Common Lisp will have to be a lot more
precise.
∂23-May-86 2156 smh@mit-ems.ARPA Re: Where Pure Common Lisp lives
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 23 May 86 21:12:18 PDT
Received: by mit-ems.ARPA (4.12/4.8) id AA02152; Sat, 24 May 86 00:10:06 edt
Date: Sat, 24 May 86 00:10:06 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8605240410.AA02152@mit-ems.ARPA>
To: snyder%hplsny@hplabs.ARPA
Subject: Re: Where Pure Common Lisp lives
Cc: common-lisp@su-ai.ARPA
> From @SU-AI.ARPA:snyder%hplsny@hplabs.ARPA Fri May 23 11:58:17 1986
>
> Here's an alternative: How about leaving LISP:MAKE-PACKAGE alone, and
> defining LOCAL:MAKE-PACKAGE to default to the LOCAL package?
You'll have to do the same for LISP:IN-PACKAGE, and you'll have to fix
the compiler to give LOCAL:IN-PACKAGE the same special attention it
gives LISP:IN-PACKAGE... It's disturbing how rapidly any hacking of
the package system gets ugly.
∂23-May-86 2156 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Common Lisp Subset
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 May 86 21:38:33 PDT
Received: from utokyo-relay by csnet-relay.csnet id aa09319; 24 May 86 0:27 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA13068; Sat, 24 May 86 12:51:13+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA28268; Sat, 24 May 86 12:34:54+0900
Date: Sat, 24 May 86 12:34:54+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8605240334.AA28268@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida@UTOKYO-RELAY.CSNET, mathis@USC-ISIF.ARPA
Subject: Common Lisp Subset
It was appeared as WGSYM 34-4 IPSJ Nov. 1985.
WGSYM is Working Group on Symbol Manipulation
IPSJ is Information Processing Society of Japan.
and was the base for subsetting discussions in Japan.
The paper is attached here.
We have a continuous talk with this paper for polishing it up.
We have a working group for it under CommonLisp committee at Jeida.
The group meeting was held twice-a-month schedule from Dec.1985 till now.
The polished version will be apperead at July 8th meeting.
The primary members are
Masayuki Ida,
K. Yuura (Hitachi),
H. Kato(Fujitsu),
S. Kawai (DEC japan),
Y. Hashimoto(NEC),
K. Umemura(NTT),
S. Harada (Sharp)
Y. Yamamura (Nippon Univac),
K. Kawagome(Sord)
and some other members extended from this April.
Mr. Yuura is the chair of the working group.
I hope this subset efforts will assist you, if you are considering
a two-level language spec like Fortran.
I feel the current disccusions on Common-lisp@su-ai have a tendency to
make Common Lisp fat, not slim.
Of cause it is needed to include rich functionality into Common-lisp,
but there are small sized machines which can not use the "full-set" CommonLisp.
I am not so enthusiastic to make a subset, but I think it will be needed,
and I have a continuous interest to make a subset or a core Common Lisp.
Here is my paper on Nov. 1985
(M.Ida: A Common Lisp Subset Proposal", WGSYM 34-4, IPSJ Nov. 1985)
-----------------------------------------------------------------------
A Common Lisp Subset Proposal
Masayuki Ida
Assoc.Prof, Aoyama Gakuin University
Chair. Jeida Common Lisp Committee
Make Common Lisp slim. Don't cut arms and legs
One and only one official subset for Common Lisp.It prevents
us from divergence of language specification among
CommonLisp-LIKE lisps
********** extracted from WGSYM 34-4 ***********
1) Is this proposal for personal computer based implementa-
tion? ---> Yes and No
YES: As prof. Fahlman said in [Fah85], personal comput-
er will grow to have much more memory space and secondary
storages. Large size personal computer will be possible to
run full set Common Lisp. But, there is a price range fac-
tor. There will be still low-end computers with popularity.
Price of the machine which may run this subset can range
among a few thousand dollars.
No: The decision upon defining subset should not in-
clude the restrictions drived from the current technology.
2) How small or slim?
A subset which is very small, cannot play the actual
roles. For example, Minimal Basic seems to be dead now for
almost every scene. Then this subset of CommonLisp should
not go to extremes. The author have an image in mind the
size is about half of full set. And may be more than 50%,
but not greatly less than 50%.
3) What is the basic policy?
Don't cut arms and legs of Common Lisp
4.2 Some technical issues
1) Do we assume compiler? ----> Yes
Interpreter plays a role of command
interpreter/debugger. As a matured language, a compiler
should be equipped.
2) DO we keep the type hierarchy? ---> Yes
Omit some types, but, preserve hierarchy (for example,
character type is independent from number)
3) Do we omit sequence type? ---> No
(for user friendlyness)
4) Do we need complex numbers? ---> No
5) Do we need the visibility of system constants and vari-
ables?
---> No (some variables and constants are left)
6) Do we need complete function sets of numbers? ---> No
preserve types except Complex numbers. delete almost
all the irrational functions
7) Do we need hash-table? ---> No
8) Do we need dynamic properties of array? ---> No
Only simple and static array. no fill-pointers, no ad-
justable array, no bit array. three dimension, not seven,
is enough.
9) How about the format feature? ---> there are two ways
1. limit the field specifier set,consulting fortran case.
subset F77 has I, F, E, L, A, '...', H, X, /, P, N, Z, BZ
,BN.
subset F77 does not have colon, S, SP ,SS, T, TL, TR, G,
and list directed editing.
2. exclude all the spec of format from subset
---> include format with restricted syntax
10) How about lambda list keyword? ---> make it slim
only &optional and &rest
11) Will include the object oriented facility? ---> No.
CommonLOOPS[Bob85] will be the standard after some dis-
cussions. But not include in this subset.
12) Do we include go/prog/tagbody? --->No
"go" structure should be rewritten with other con-
structs. In Common Lisp, go is not always equivalent to a
simple jump instruction. prog is obsolete. If there is no
"go", tagbody is meaningless.
13) Keyword arguments ? -> restrict to the special cases.
So parser will be easier ( general parsing mechanism for
keyword is not needed)
5.Summary of the subset spec
Total: 330 functions, 2 constants, 7 variables (Table 1).
Notation of the following summary:
1) listed elements are included in subset spec.
2) single braketted elements ([ ... ]) are OMITTED.
3) double braketted elements ([[ ... ]])
have RESTRICTED syntax/semantics
4) triple braket ([[[ ... ]]]) contains comments
Chapter 2 Data Type
number, integer, fixnum, bignum, ratio, float, short-
float,single-float, double-float, long-float, [omit: com-
plex]
character, standard-char, string-char, [[[comment:
bits-attribute and font-attribute may be zero]]]
symbol,list,cons,null
array, [[restricted: max rank=3, array means simple-
array]], [omit: bit vector]
[hash table]
[[ readtable;restricted to only one readtable]]
[package, pathname, stream, random-state]
structure, function
2.15 type overlap,inclusion,disjointeness
[[[ preserve data type hierarchy of full set. hierar-
chy figure is defined as in [ida84] ]]]
Chapter 3. Scope and Extent
[[[same scoping as full set]]]
Chatpter 4. type specifier
standard type specifiers of Fig.4.1 are all active,
coerce, typeof, readtable, simple-array, simple-bit-vector,
simple-string, simple-vector
[bit, bit-vector,complex,hash-table, stream, ]
[And omit functions such as deftype, type specifier
combination, predicating specifier(satisfies)]
Chapter 5. Porgram structure (2 functions)
defun,defvar
[omitted functions from Fig 5.1; tagbody, macrolet,
flet, compiler-let, eval-when,go]
[&key,&allow-other-keys,&aux from lambda-list keyword,
lambda-list-keyword, lambda-parameters-limit, defparameter,
defconstant]
Chapter 6. predicates (27 functions, 2 constants)
nil, t, typep, subtypep, null, symbolp, atom, consp,
listp, numberp, integerp, rationalp, floatp, characterp,
stringp, vectorp, simple-vector-p, simple-string-p, arrayp,
packagep, functionp, compiled-function-p, commonp, eq, eql,
equal, not, and, or
[complexp, bit-vector-p, simple-bit-vector-p, equalp]
Chapter 7. Control Structure (51 functions)
quote, function, symbol-value, symbol-function, boundp,
fboundp, special-form-p, setq, psetq, set, makunbound,
fmakunbound, setf, apply, funcall, progn, prog1, prog2, let,
let*, progv, labels, if, when, unless, cond, case, block,
return-from, return, loop, do, do*, dolist, dotimes, ma-
plist, mapcar, mapc, mapl, mapcan, mapcon, values, values-
list, multiple-value-list, multiple-value-prog1, multiple-
value-bind, multiple-value-setq, multiple-value-call, catch,
unwind-protect, throw
[psetf, shiftf, rotatef, defsetf, define-setf-
method, define-modify-macro, get-setf-method, get-setf-
method-multiple-value, call-argument-limit, compiler-let,
flet, macrolet, prog, go, typecase, tagbody]
setf accessible forms;
aref, car, cdr, c...r, fill-pointer, first, get, getf,
nth, nthcdr, rest, second, symbol-function, symbol-plist,
symbol-value, third, access function of defstruct,
[omitted access form; elt,fourth--
tenth,svref,gethash,documentation, c....r, macro-function,
(char, schar, bit, sbit, subseq) function calls, the-
declaration, apply ]
Chapter 8. Macro (5 functions)
macro-function, defmacro, macro, macroexpand,
macroexpand-1
[[ defmacro keywords only to &optional and &rest]]
[omit *macro-expand-hook*, &key, &allow-other-keys,
&aux, &body, &whole, &environment]
Chapter 9. Declarations (2 functions)
Only (declare (special ...)) acceptable
[omit all the spec of declarations but above]
[[["the" acceptable but not effective]]]
Chapter 10. Symbols (10 functions)
get, remprop, symbol-plist, getf, remf, symbol-name,
make-symbol, copy-symbol, gensym, keywordp
[get-properties, gentmp, symbol-package]
Chapter 11. Package (1 function)
[All the spec of Package features are omitted,but
below]
11.1 consistency rules, intern
Chapter 12. Number (51 functions)
zerop, plusp, minusp, oddp, evenp, =, /=, <, >, <=, >=,
max, min, +, -, *, /, 1+, 1-, incf, decf, gcd, lcm, exp,
expt, log, sqrt, abs, signum, sin, cos, tan, rational, ra-
tionalize, numerator, denominator, float, floor, ceiling,
truncate, round, mod, rem, logior, logxor, logand, logeqv,
lognot, logtest. logbitp, ash
[[ complex related features of above fuctions are omit-
ted]]
[ complex and byte-manipulation functions, random-
numbers, implementation parameters described in 12.10.
conjugate, isqrt, phase, cis, asin, acos, atan, pi,
sinh, cosh, tanh, sinh, acosh, atanh, ffloor, fceiling,
ftruncate, fround, decode-float -- integer-decode-float,
complex, realpart, imagpart, lognand, logandc1, logandc2,
logorc1, logorc2, boole, bool- constants byte, byte-size,
byte-position, ldb, ldb-test, mask-field, dpb, deposit-
field, random, *random-state*, make-random-state ]
Chapter 13. Characters (21 functions)
standard-char-p, alpha-char-p, upper-case-p, both-
case-p, digit-char-p, char=, char/=, char<, char<=, char-
code, code-char, make-char, char-upcase, digit-char, char-
int, int-char, char-downcase, char-name, name-char, char-
bit, set-char-bit
[ char-code-limit, char-font-limit, char-bits-limit,
graphic-char-p, string-char-p, alphanumericp, char-equal,
char-not-equal, char-lessp, char-greaterp, char-not-
greaterp, char-not-lessp, char>, char>=, 13.5 char control
bit functions ]
Chapter 14. Sequences (17 functions)
subseq, reverse, nreverse, some, every, notany,
notevery, sort
[[as to fill pointer:: elt,length]]
[[as to :start - :end :: remove, remove-if, remove-
if-not, remove-duplicates, find, position, count]]
:count, :from-end, :strat, :end, make-sequence, con-
catenate, map, reduce, fill, replace, delete, delete-if,
delete-if-not, delete-duplicates, substitute, substitute-if,
substitute-if-not, nsubstitute, nsubstitute-if,
nsubstitute-if-not, find-if, find-if-not, position-if,
position-if-not, count-if, count-if-not, mismatch, search,
stable-sort, merge ]
Chapter 15. list (62 functions)
car, cdr, c..r, c...r, cons, tree-equal, endp, list-
length, nth, first, second, third, rest, nthcdr, last, list,
list*, append, copy-list, copy-alist, copy-tree, nconc,
push, pushnew, pop, butlast, nbutlast, ldiff, rplaca,
rplacd, pairlis
[[keyword not allowed; subst, nsubst, sublis, member,
member-if, member-if-not, adjoin, union, nunion, intersec-
tion, nintersection, set-defference, nset-difference, set-
exclusive-or, nset-exclusive-or, assoc,assoc-if, assoc-if-
not, rassoc, rassoc-if, rassoc-if-not]]
[c....r, fourth -- tenth, make-list, revappend,
nreconc, subst-if, subst-if-not, nsubst-if, nsubst-if-not,
subsetp, acons, tailp]
Chapter 16. Hash-table (0 functions)
[ ALL ]
Chapter 17. Array (6 functions)
vector, aref, array-rank, array-in-bounds-p, array-
total-size
[[ make-array( limit to three dimensions (not seven),
all the keyword arguments but :initial-contents are delet-
ed)]]
[ array-rank-limit, array-dimension-limit, array-total-
size-limit, svref, array-elemet-type, array-dimension,
array-dimensions, array-row-major-index, adjustable-array-p,
bit, sbit, bit-and, bit-or, ..., bitorc2, bit-not, array-
has-fill-pointer-p, fill-pointer, vector-push, vector-push-
extend, vector-pop, adjust-array, 17.4 all (bit-array),17.5
all (fill pointer),17.6 all (augumentation of dimension) ]
Chapter 18. string (9 functions)
char, string-trim, string-left-trim, string-right-trim,
string-capitalize
[[ subseq(:start and :end) related restriction ::
string=, string/=, string<, string<=]]
[schar, string>, string>=, string-equal, string-lessp,
...,make-string, string-upcase, string-downcase, nstring-
upcase, nstring-down-case, nstring-capitalize]
Chapter 19. structure (1 functions)
[[ defstruct ]]
[ :type,:read-only (in defstruct slot option),
:conc-name, :constructor, :copier, :predicate, :include,
:print-function, :type, :named, :initial-offset (in defs-
truct option), by-position constructor ]
Chapter 20. Evaluator (1 function)
eval
[ evalhook, applyhook, *evalhook*, *applyhook*, con-
stantp, +, ++, +++, -, *, **, ***, /, //, /// ]
Chapter 21. stream (1 function, 7 variables)
*standard-input*, *standard-output*, *error-output*,
*query-io*, *debug-io*, *terminal-io*, *trace-output*
[[ close (No :abort arg) ]]
[make-synonym-stream, make-...-stream, get-output-
stream-string, with-input-from-string, with-output-to-
string,streamp, input-stream-p, output-stream-p, stream-
element-type ]
Chapter 22. input/output (22 functions)
22.1.4 dispatching macro character
#',#(,#+,#-,#B,#D,#S,#X,#nA,#|
[#\,#*,#:,#.,#,,#O,#nR,#n=,#n#,#<,#)]
22.1.5 [*readtable*, copy, readtable, readtablep, set-
syntax-from-char, set/get-macro-character, make-dispatch-
macro-character, set/get-dispatch-macro-character ]
22.1.6 [*print-...* all omitted]
22.2 input
read, read-line, read-char, unread-char, listen, read-
char-no-hang, clean-input, read-byte
[*read-default-float-format*, read-preserving-
whitespace, read-delimited-list, peek-char, parse-integer]
[[ read-from-string (no keyword arg) ]]
22.3 output
write-byte, prin1, print, pprint, princ, prin1-to-
string, princ-to-string, write-char, terpri, fresh-line,
format, y-or-n-p, yes-or-no-p
22.3.3 format specifier:
~A, ~S, ~D, ~X, ~C, ~F, ~E, ~%, ~&, ~|, ~~, ~<newline>,
[~B, ~O, ~nR, ~P, ~G, ~$, ~T, ~*, ~?, ~(str~),
Chapter 23.file system interface (11 functions)
23.1 file name pathname
file name should be string
[all the pathname related definitions are omitted]
23.2 file open/close
open
[[file name should be string (:direction is Only input
or output, :element-type is only string-char or unsigned-
byte, :if-exists omitted, :if-does-not-exist omitted)]],
with-open-file
23.3 rename-file, delete-file, probe-file, file-write-date,
file-author, file-position, file-length
23.4 [[load(no keyword)]], [*load-verbose*]
23.5 directory
Chapter 24. error (4 functions)
error, cerror, warn, break
[ *break-on-warning*, check-type, assert, etypecase,
ctypecase, ecase, ccase]
Chapter 25. miscellaneous (26 functions)
compile, compile-file, documentation, trace, untrace,
step,time, describe, inspect, room, ed, dribble, appropos,
appropos-list, get-decoded-time, get-internal-run-time,
get-internal-real-time, sleep, lisp-implementation-type,
*features*, lisp-implementation-version, machine-type,
machine-version, machine-instance, software-type, software-
version
[disassemble, get-universal-time, decode/encode-
universal-time, internal-time-units-per-second, short-site-
name, long-site-name, identity]
------------------------end of the document ----------
----------
∂24-May-86 0950 RAM@C.CS.CMU.EDU Common Lisp Subset
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 24 May 86 09:48:20 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 24 May 86 12:47:17-EDT
Date: Sat, 24 May 1986 12:47 EDT
Message-ID: <RAM.12209278016.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Cc: common-lisp@SU-AI.ARPA, ida.UTOKYO-RELAY@CSNET-RELAY.ARPA,
mathis@USC-ISIF.ARPA
Subject: Common Lisp Subset
In-reply-to: Msg of Sat 24 May 86 12:34:54+0900 from Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at CSNET-RELAY.ARPA>
Out of curiousity, I went through the Spice Lisp sources and
counted all the code that we could eliminate if we were implementing
your subset instead of Common Lisp. I counted about 12,000 lines of
code. This is out of the 40,000+ lines of code in Spice Lisp
which implement the Common Lisp specification.
These figures don't include the compiler, but then none of your
restrictions help the compiler a great deal. The only significant one
is elimination of keyword args.
Largely what you propose is the elimination of many facilities which
are easily defined in terms of other facilities. This may be a good
criterion for eliminating them on esthetic grounds, but it isn't the
best way to reduce resource requirements. An example is the
restrictions on the irrational functions. Your changes only eliminate
25% of our irrational code. This is because the strange irrational
functions and complexes are defined in terms of the basic functions
which you do require.
In other cases, things that you eliminate will have to exist
anyway to support things that you require. For example, Decode-Float
is used to implement the irrational functions.
If you set out to build an entire implementation with minimal
memory usage, then you could probably build one quite a bit smaller
than Spice Lisp. It is unclear whether in such a minimal
implementation, the effect of your restrictions would be larger or
smaller than in Spice Lisp. Many of the features that you propose to
eliminate are quite amenable to simplification at the cost of
efficiency, possibly more so than the ones to propose to retain.
Some of your restrictions are legal in Common Lisp
implementations. Declarations may be ignored, THE is ignorable, and
several implementations don't have DISASSEMBLE.
You have avoided eliminating the big "iceberg" features such as
full lexical scoping and full rational arithmetic. These are features
which take little text to describe, but much code to implement. This
does make the subsetting less traumatic, but it isn't the most
effective way to eliminate resource requirements.
It seems that you set out to eliminate 50% of the tokens from the
language, and have done so. In the process of eliminating everything
that was easy to eliminate, you have only reduced the real complexity
of the language by about 25%. While it is true that there will always
be a price/performance range in computers, a 25% reduction in required
performance will probably bring a smaller reduction in price. It is
also true that there are effective lower bounds on price and
performance.
Today it is hard to get a personal computer with less than 64k of
memory; ten years ago it was hard to get a personal computer with more
then 64k. The question is how long is the performance window of
subset Common Lisp v.s. full Common Lisp going to be open. In your
example of a too-small subset, you mentioned miminal basic. The real
problem with minimal basic is that there is no machine today which
cannot run a full basic. Remember the "standard" 4k basic and the
"extended" 16k basic? It's no surprise you don't hear much about 2k
tiny basics anymore.
Rob
∂24-May-86 1024 @MIT-LIVE-OAK.ARPA:JerryB@GOLD-HILL-ACORN.LCS.MIT.EDU Where Pure Common Lisp lives
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 24 May 86 10:23:55 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 1736; 24 May 86 13:23:43-EDT
Received: from VENEZUELA.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 20922; Sat 24-May-86 10:42:31-EDT
Date: Sat, 24 May 86 10:20 EST
From: JerryB@a
To: Moon@SCRC-STONY-BROOK.ARPA
Subject: Where Pure Common Lisp lives
Cc: COMMON-LISP@SU-AI.ARPA
Date: Fri, 23 May 86 20:54 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: Fri, 23 May 1986 14:57 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Hmmmm...is USER allowed to start up with random local extensions in it,
or is it supposed to inherit ONLY from the LISP package, which is now
pure Common Lisp? How have people been reading this? Part of my
objection to making LISP pure was because I assumed that this meant USER
had to be pure as well, which means that we need another standard place
to look for the default local environment.
I always assumed USER was supposed to have everything in it. I guess this
is not written down anyplace, though. Sigh.
...
I have assumed that USER should contain everything as well. One
reason being the desire to minmize complexity (knowledge of the
package system) for new users. New users will frequently use local
extensions.
∂24-May-86 1233 smh@mit-ems.ARPA Re: LISP:*LOCAL-PACKAGE*
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 24 May 86 12:32:25 PDT
Received: by mit-ems.ARPA (4.12/4.8) id AA04942; Sat, 24 May 86 15:29:26 edt
Date: Sat, 24 May 86 15:29:26 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8605241929.AA04942@mit-ems.ARPA>
To: KMP@SCRC-STONY-BROOK.ARPA
Subject: Re: LISP:*LOCAL-PACKAGE*
Cc: common-lisp@SU-AI.ARPA
>From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
>
>LISP - a pure CL package to make the hard-core portability folks happy.
>
>LISP:*LOCAL-PACKAGE* - a variable holding the a package which is named
> (hopefully uniquely) in a system-dependent way by each implementation.
> This should use LISP. There's a minor issue about whether this should
> be a system constant (no stars) or a settable variable. I'm not fussy.
>
>USER - a package which uses LISP and which uses the package which is the
> value of LISP:*LOCAL-PACKAGE* .
>
>MAKE-PACKAGE,etc - as before, but if no package is explicitly given to
> use, the default would be LISP:*LOCAL-PACKAGE* . Writers of most portable
> code would use LISP explicitly.
I agree with the intention, but some of the details are unclear. There
are two ways the local-extension package could work:
(1) LISP:*LOCAL-PACKAGE* exports only the extension symbols. USER and
other user-created packages must use both it and LISP.
(2) LISP:*LOCAL-PACKAGE* also exports all the normal external symbols
in the portable LISP package, except those that it might want to shadow
with distinct versions.
Your descriptions of USER and MAKE-PACKAGE above seem to imply
different choices. Anyway, for several reasons (2) seems cleaner:
It is less of a change from the current spec since packages created
with the `default' still will only use a single package (even though
it's name might not be LISP) rather than two packages.
If an implementation for some reason shadows a standard function
symbol under (1), the user cannot naively create a new package which
uses both LISP:*LOCAL-PACKAGE* and LISP without also doing explicit
shadowing.
If we choose (2) it is insufficient (or irrelevant?) for
LISP:*LOCAL-PACKAGE* to use LISP. Inherited symbols are not
automatically exported. The following has to happen (for simplicity,
assuming no shadowing is necessary):
(LET ((LOCAL (FIND-PACKAGE :LOCAL)))
(DO-EXTERNAL-SYMBOLS (SYM (FIND-PACKAGE :LISP))
(EXPORT SYM LOCAL)))
∂24-May-86 1402 kempf%hplabsc@hplabs.ARPA Re: Common Lisp Subset
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 24 May 86 14:01:53 PDT
Received: from hplabsc by hplabs.ARPA ; Sat, 24 May 86 13:59:58 pdt
Received: by hplabsc ; Sat, 24 May 86 14:00:47 pdt
Date: Sat, 24 May 86 14:00:47 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.ARPA>
Message-Id: <8605242100.AA20249@hplabsc>
To: common-lisp@SU-AI.ARPA
Subject: Re: Common Lisp Subset
> Today it is hard to get a personal computer with less than 64k of
>memory; ten years ago it was hard to get a personal computer with more
>then 64k. The question is how long is the performance window of
>subset Common Lisp v.s. full Common Lisp going to be open. In your
I think there is an additional issue here besides simply reducing
resource requirments, and that is one of language design principles.
Should the language designer provide a rich language with lots of
features (like PL/I and Common Lisp) or rather a minimal set
of orthogonal features which programmers can build upon (like C
and Smalltalk)? An argument for the former is that it allows
programmers to start at a higher level, reducing the need for
porting lower level packages. An argument for the latter is
conceptual simplicity and enhancement of the programmer's
ability to tune the application to resource requirements
("you only pay for what you use").
Jim Kempf kempf@hplabs
∂24-May-86 2312 hpfclp!diamant@hplabs.ARPA Re: LISP:*LOCAL-PACKAGE*
Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 24 May 86 23:07:49 PDT
Received: by hplabs.ARPA ; Sat, 24 May 86 23:06:08 pdt
Date: Sat, 24 May 86 23:06:08 pdt
From: hpfclp!diamant@hplabs.ARPA
To: common-lisp@su-ai.ARPA
Subject: Re: LISP:*LOCAL-PACKAGE*
> From: Kent M Pitman <hplabs!KMP@SCRC-STONY-BROOK.ARPA>
>
> OK. This is starting to sound pretty good. Based on your message and the
> others that have gone by, what would make me happy would be...
>
> LISP - a pure CL package to make the hard-core portability folks happy.
Great.
>
> LISP:*LOCAL-PACKAGE* - a variable holding the a package which is named
> (hopefully uniquely) in a system-dependent way by each implementation.
> This should use LISP. There's a minor issue about whether this should
> be a system constant (no stars) or a settable variable. I'm not fussy.
It should also export all of LISPs exported symbols, and all of the symbols
exported from LISP should be homed in LISP.
You have convinced me that the name of the local package should not be
standard, but instead to use a standard mechanism to access it.
If you allow *LOCAL-PACKAGE* to be a variable, you will shoot yourself in the
foot. What happens if you change the value? Will all subsequent MAKE-PACKAGEs
reflect the new value (good idea)? So far this is no problem, but if you
want to really make it control the default environment (otherwise why not
use a constant), it should also change the use list of the USER package.
There is currently no mechanism for packages on the use list to be tied to
the value of a variable (nor should there as it would make manipulating the
use list more complicated). You would require a function as I had suggested
in a previous message or an object with a setf method in order to be able to
change the use list of the USER package. It is conceivable that the USER
package would use the original value, and subsequent MAKE-PACKAGEs would use
the current package, but it seems conceptually unclean. My attitude
about this is due to my view of the USER package as a reasonable place
for portable programs to live (which differs from Alan Snyder's view).
Given that view, I would like the USER package to have the same
characteristics as ones I make with subsequent calls to MAKE-PACKAGE.
I had always assumed that the USER package should use LISP (as it says in
CLtL) and nothing else. I don't mind having it use the default environment
for convenience, but realize that this makes programs which are now portable
(in that they assume that no less and no more than what is defined in CLtL
is in the implementation on which they run), no longer portable until they
change all their MAKE-PACKAGEs to explicitly use LISP, so that they don't
get the default environment and/or change the value of *LOCAL-PACKAGE* to
be LISP. I would be happier if a mechanism were set up where the default was
the current status quo (i.e. the bare environment), but the variable (or
whatever mechanism used) could be set to the implementation dependent package.
> USER - a package which uses LISP and which uses the package which is the
> value of LISP:*LOCAL-PACKAGE* .
>
> MAKE-PACKAGE,etc - as before, but if no package is explicitly given to
> use, the default would be LISP:*LOCAL-PACKAGE* . Writers of most portable
> code would use LISP explicitly.
>
>
> Thoughts, anyone?
I think it is time we start thinking about writing a guide for writing
portable programs in Common Lisp. It is clear that this is not as simple
a matter as had originally been suspected, and at present neither implementors
nor users have such a guide. It should be part of the ANSI standard
document.
John Diamant
∂26-May-86 1801 FAHLMAN@C.CS.CMU.EDU Where we stand
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 May 86 18:01:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 26 May 86 21:01:06-EDT
Date: Mon, 26 May 1986 21:01 EDT
Message-ID: <FAHLMAN.12209892202.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Where we stand
A progress report from the Technical Committee is overdue. Here's where
things stand:
First, the technical and steering committees have held electronic
elections. I have been elected chariman of the technical committee
through the end of 1986. Bob Mathis has been elected chairman of
the steering committee. Both of us have the model that the main
function of the chariman is to keep things moving and to moderate the
discussions. As his messages have indicated, Bob has been moving along
with the process of getting all this organized properly within ANSI and
ISO.
Second, we have been thinking about how to proceed on the technical
side. Most of us favor a model in which we start with an online version
of the manual. Issues would be debated on the Common Lisp mailing list
and, when things have settled as much as they are going to, the
technical committee would make a decision. Each such decision is folded
immediately into the manual, which is available online to everyone. At
some point we decide we're done and send the document over to ANSI with
our recommondation that this become the new standard for Common Lisp;
ANSI then decides, and we go from there to ISO. Up to the point where
ANSI makes a decision, all of this is just a set of proposals for a
language spec, though implementaiton groups are free to act on these
recommendations if they choose to.
It would probably be best to use the Digital Press book as the starting
point if we can obtain the necessary rights; an alternative is to start
from a manual Lucid has developed which is meant to describe the same
language, but in different words, if we can obtain the necessary rights
from Lucid. The worst option is to develop a new docuemnt from scratch
-- a lot of redundant work, plus the likelihood that we will introduce
some new ambiguities. We need to obtain, from Digital Press or Lucid or
both, the right to create a derivitive work that is intended to be used
as a specification document, while those companies keep the copyright on
their original version. We are trying to work out exactly who should
own the rights to the revised document. ANSI normally owns the
copyright on their standards and makes some money selling the documents,
but in this case we are determined that the final document should be
readily available to everyone at a low price and that the text can be
used by companies to create online and printed documents for their own
products without a lot of red tape. None of us wants to put a lot of
work into this document and then find that someone else controls the use
of it.
As you can imagine, this document situation raises all sorts of
complicated legal issues, and it is going to take us some time to cut
through it all. Lawyers don't work very fast. I want to resolve a lot
of the technical issues over the summer and have a document ready for
submission to ANSI by the end of the year, and if we are to meet that
goal we must get moving. And so, reluctantly, I propose that we begin
trying to resolve issues a few at a time, and that we just record the
decisions in an online file until we have a document that we can start
working on. This means that we'll need a separate pass later on to
incorporate the decisions into a document, and there is the danger that
we'll inadvertently introduce new bugs at that time, but I see no good
alternative. We can't wait around any longer.
If people don't object to this plan, we'll get started soon. I'll begin
by sending out a message proposing some principles about how
conservative we want to be, and when we've got some general agreement
on that we can start on our backlog of issues.
In addition to resolving known problems, especially in the area of code
portability, we must agree on a reasonably complete error system. It is
not absolutely essential, but I believe it would be very beneficial if
we can agree on a set of object-oriented facilities in time to get them
into this spec. Progress on iteration, windows/graphics, and standard
subsets would be welcome, but not essential.
-- Scott
∂27-May-86 0955 DCP@SAPSUCKER.SCRC.Symbolics.COM Re: Where Pure Common Lisp lives
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 27 May 86 09:54:57 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23555; Tue 27-May-86 12:50:31 EDT
Date: Tue, 27 May 86 12:54 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: Re: Where Pure Common Lisp lives
To: Steven Haflich <smh@MIT-EMS.ARPA>, snyder%hplsny@HPLABS.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8605240410.AA02152@mit-ems.ARPA>
Message-ID: <860527125422.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sat, 24 May 86 00:10:06 edt
From: Steven Haflich <smh@mit-ems.ARPA>
> From @SU-AI.ARPA:snyder%hplsny@hplabs.ARPA Fri May 23 11:58:17 1986
>
> Here's an alternative: How about leaving LISP:MAKE-PACKAGE alone, and
> defining LOCAL:MAKE-PACKAGE to default to the LOCAL package?
You'll have to do the same for LISP:IN-PACKAGE, and you'll have to fix
the compiler to give LOCAL:IN-PACKAGE the same special attention it
gives LISP:IN-PACKAGE... It's disturbing how rapidly any hacking of
the package system gets ugly.
It's not in Chapter 11 for nothing...
∂27-May-86 1146 FAHLMAN@C.CS.CMU.EDU Keeping track of decisions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 May 86 11:45:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 27 May 86 14:44:24-EDT
Date: Tue, 27 May 1986 14:44 EDT
Message-ID: <FAHLMAN.12210085770.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Keeping track of decisions
As several people have pointed out, we should keep a list of all
official changes and decisions in a separate file, in addition to making
the appropriate changes in the evolving document. That way,
implementors will not have to scan the new manual looking for
differences between that ans Steele and wondering if such differences
are intentional. This was my intent all along, but I forgot to mention
this in the earlier mail. We will probably number and date each of these
decisions, just to make it clear when things have gone from discussion
to decided (where "decided" means that it will definitely be in the
proposal we produce).
-- Scott
∂27-May-86 1355 LOOSEMORE@UTAH-20.ARPA portability
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 27 May 86 10:43:35 PDT
Date: Tue 27 May 86 11:41:42-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: portability
To: common-lisp@SU-AI.ARPA
Message-ID: <12210074365.15.LOOSEMORE@UTAH-20.ARPA>
Here's my two cents worth on the code portability issue. I think I've
probably had as much experience with writing portable Lisp code as anyone
here, being one of the chief PCLS architects (currently running under Unix
and VMS), and having written a large amount of application code which has
been ported to other CL implementations.
I'm probably going to get flamed for this, but in my view, the name of the
package containing local extensions, or exactly what symbols live in the
Lisp package, are fairly trivial issues. My experience has been that, if
you want your code to be portable, you have to put a lot of effort into
making it that way from the beginning, and there are many problems more
troublesome than obscure package manipulations that you have to overcome
in the process. Here's a few of the issues that come to mind:
1. You can't count on being able to directly manipulate pathname
components. Explicit namestrings generally lose too.
2. There is no agreement on what *features* should contain, or what
package the symbols live in. Hence, you can't really depend on #+ and #-
to do anything useful.
3. Loading files can really be a nuisance, particularly if you want to
be able to look for them in more than one place, or if you want to look
for them somewhere other than the default directory. "Require" can be made
to do the right thing in some implementations but not others. "Load" is
OK if you can somehow get a pathname built. (I don't really have a good
solution for this problem; in PCLS we use a few global variables to hold
the names of various system-dependent files and where to look for them.)
4. It's amazing how certain implementations that don't admit to being
subsets are missing huge amounts of functionality.
5. Handling for streams regarding prompting, buffering, terminal
interrupts, etc. varies widely between implementations, depending on what
the primitives offered by the operating system are. (The VMS and Unix
versions of PCLS don't even behave the same in this respect.)
6. Lack of a portable error-handling mechanism makes it tough to do
stand-alone applications that will be used by non-Lisp wizards. (Popping
into the debugger is fine for developers, but doesn't do much for random
users who think that Lisp is what they speak in San Francisco....)
Hopefully this will change in the near future.
7. There is no standardized model about what kinds of processing happens
at compile time, particularly regarding defining forms such as deftype and
defstruct, or perverse manipulations of the package system (setq'ing
*package* directly?) Code that works fine interpretively often fails to
compile correctly.
My general approach to portability is to avoid the use of implementation-
specific or poorly standardized features where possible, and where I must
refer to them, put all the references in a separate file and wrap an
interface function around them. It makes it a lot easier when everything
you need to tweak to get the code to run under a different implementation
is all in one place instead of scattered randomly through two dozen files.
-Sandra Loosemore
-------
∂27-May-86 2206 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM MAKE-ECHO-STREAM, and related issues
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 27 May 86 22:05:50 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9525; Wed 28-May-86 01:03:32 EDT
Date: Wed, 28 May 86 01:03 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: MAKE-ECHO-STREAM, and related issues
To: Common-Lisp@SU-AI.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA
Message-ID: <860528010335.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Assuming that "FOO" is a file containing the single character "X", consider
the expression:
(WITH-OPEN-FILE ((STREAM "FOO" :DIRECTION :INPUT))
(LET ((ECHO-STREAM (MAKE-ECHO-STREAM STREAM *TERMINAL-IO*)))
(PEEK-CHAR ECHO-STREAM)
(PRIN1 'FOO)
(READ-CHAR ECHO-STREAM)))
Should this print "XFOO" or "FOOX"? I'll argue strongly that it's pretty
critical that it be "XFOO" since it's easy for the user to simulate the
"FOOX" behavior and next to impossible to simulate the other behavior.
Does anybody buy that? Can anyone find a passage in CLtL where it says
one way or the other what happens in this case? The doc on p330 is
completely vague on the issue.
In general, I think we should be clear on the fact that any peek operation
must not echo. For example, a system which is full duplex and not
line-at-a-time (and hence must decide to echo the char either at the first
peek-char or at the read-char) should wait until the read. Among other
things, failure to do this keeps you from writing a reader which can
correctly handle a prompted read of foo'foo as two separate expressions.
You end up seeing:
Form: foo'
Form: foo
rather than
Form: foo
Form: 'foo
Form:
On a line-at-a-time system, where the input is echoed at prescan time, you
end up seeing:
Form: foo'foo
Form:
Form:
which is not optimal, but is probably tolerable since users of such systems
are probably used to this sort of effect. In fact, using LISTEN, you can can
write something which (barring timing errors due to high-speed typists)
heuristically manages to optimize out the intermediate prompt.
Would people be willing to agree that we should have a way to detect whether
the terminal, implementation, or whatever was line-at-a-time or not, or is
that too ill-defined? It would certainly be very useful to code which wants
to do something graceful in the face of radically varying styles of input
scanning.
∂27-May-86 2222 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM PEEK-CHAR
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 27 May 86 22:22:41 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9535; Wed 28-May-86 01:20:29 EDT
Date: Wed, 28 May 86 01:20 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: PEEK-CHAR
To: Dave.Touretzky@CMU-CS-A.ARPA
cc: COMMON-LISP@SU-AI.ARPA
References: The message of 28 May 86 01:17-EDT from Dave.Touretzky@A.CS.CMU.EDU,
<860528010335.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <860528012039.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 28 May 86 01:17 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Re: MAKE-ECHO-STREAM, and related issues
If you don't want peeks to echo, shouldn't your example print "FOOX"
rather than "XFOO" ? You said the opposite in your message.
Oops. Yes, indeed.
"FOOX" is what I meant to say should happen by default.
"XFOO" is the easy one to simulate given the other.
Sorry for the confusion; thanks for catching it.
∂28-May-86 1609 Pavel.pa@Xerox.COM Is &body REALLY like &rest?
Received: from XEROX.COM by SU-AI.ARPA with TCP; 28 May 86 16:09:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 MAY 86 16:08:52 PDT
Date: 28 May 86 16:08 PDT
From: Pavel.pa@Xerox.COM
Subject: Is &body REALLY like &rest?
To: Common-lisp@SU-AI.ARPA
Message-ID: <860528-160852-1701@Xerox>
Another in a long series of clarifications of clarifications is
requested.
In CLtL, page 145, it says
``&body This is identical in function to &rest...''
In Guy's clarifications, it says
``145 Extend the syntax of an &body parameter to DEFMACRO to allow
writing
&body (body-var [declarations-var [doc-var]])''
so as to make it easy to call PARSE-BODY.
In CLtL, page 146, it says
``Anywhere in the lambda-list where a parameter name may appear and
where ordinary lambda-list syntax ... does not otherwise allow a list,
a lambda-list may appear in place of the parameter name.''
This allows for destructuring.
Question: Does the following DEFMACRO do destructuring or does it call
PARSE-BODY?
(defmacro foo (&rest (a b c)) (bar a b c))
The real question is whether or not the clarification introduced a
difference in the meanings of &rest and &body. One possible
interpretation is that a list after &rest does destructuring and a list
after &body implies a call to PARSE-BODY.
Which one is right?
Pavel
∂28-May-86 1742 somewhere!yuasa@kurims.kurims.kyoto-u.junet
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 28 May 86 17:40:19 PDT
Received: by su-shasta.arpa; Wed, 28 May 86 17:38:28 PDT
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA12890; Wed, 28 May 86 11:33:42 jst
From: yuasa@kurims.kurims.kyoto-u.junet
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA12880; Wed, 28 May 86 11:33:08 jst
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA00192; Wed, 28 May 86 10:39:30+0900
Date: Wed, 28 May 86 10:39:30+0900
Message-Id: <8605280139.AA00192@kurims.kyoto-u.junet>
To: common-lisp@su-ai.arpa
Date: Fri, 23 May 86 17:34 EDT
From: Charles Hornig <Shasta!Hornig@SCRC-RIVERSIDE.ARPA>
Date: Fri, 23 May 86 05:50:43 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Is there an official 'online' list of the external lisp package
symbols implied by the Common Lisp book? If not, I'd like to
start the process of computing the list by supplying the following
list which I believe to be very close to correct. Are there any
additions or deletions?
...list removed...
I would add COMPILATION-SPEED and remove SEQUENCEP.
I would remove KEYWORD.
-- Taiichi
∂28-May-86 2004 Moon@SCRC-QUABBIN.ARPA Are isomorphic structures EQUAL?
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 28 May 86 20:04:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 3367; Wed 28-May-86 18:40:45 EDT
Date: Wed, 28 May 86 18:37 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Are isomorphic structures EQUAL?
To: common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]11-Apr-86 16:43:13.NGALL>
Message-ID: <860528183719.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 11 Apr 1986 16:43-EST
From: NGALL@G.BBN.COM
I don't want to reopen the discussion that we had about equality a
while back, but someone in my group just tripped over an ambiguity in
the manual.
She was using DEFSTRUCT with the (:TYPE ...) option and using EQUAL to
compare structures and everything worked fine since EQUAL did a
component-wise equality test.
Then she got bold and decided to let DEFSTRUCT choose the
representation, so she left off the (:TYPE ...) option. Low and
behold, EQUAL did not do a component-wise equality test, it tested for
EQL!
So she looked at the def. on page 80 where it said "Certain objects
that have components are EQUAL if they are of the same type and
corresponding components are EQUAL." Unfortunately, the rest of the
definition did not make it at all clear whether or not objects created
by DEFSTRUCT were among these "Certain objects". Looking on the next
page at the def. of EQUALP (which happened to do a component-wise
equality test), she read "Objects that have components..." The only
difference was the word "Certain"!
So we tried it on another CL (SymbolicsCL), and got the same behavior
(as with VaxLisp). Which leads me to almost believe that EQUAL NOT
supposed to to a component-wise test for equality. Except...
What happens to implementations that want to represent structures
using plain old vectors? How will EQUAL distinguish vectors from
structure-vectors?
As Rees pointed out, such an implementation would not be legal.
This interaction of DEFSTRUCT/EQUAL is going to cause a lot of bugs.
People are going to prototype structues using the (:TYPE LIST) option
and use EQUAL to do equality tests. Then when they remove the :TYPE
option, KaBoom!
I don't think that's a plausible way to program, but I agree that "equality"
is an area of the language that needs work.
There will be no way to do a component-wise test (using EQUAL on each
component) on two structures unless one writes a structure-specific
equality predicate.
Therefore, I propose that two structures of the same type that are
created by DEFSTRUCT (regardless of the :TYPE option) be tested for
equality component-wise and that the CLtL make this clear.
Until then, she can get by with EQUALP (since her structures don't
conatin strings, floats, etc.).
I don't understand this. I can't find anything in the manual that says
that EQUALP behaves differently than EQUAL for structures. Actually I
can't find anything in the manual that says anything at all about the
behavior of either EQUAL or EQUALP on structures.
It may be that by coincidence the two implementations you mentioned in
your message both compare components of structures (with the default
defstruct options, especially no :TYPE) in EQUALP, and do not compare
components of structures in EQUAL, but I don't think the Common Lisp
manual says that all implementations have to do that.
∂28-May-86 2230 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM *DEBUG-IO*
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 28 May 86 22:30:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 10590; Thu 29-May-86 01:27:43 EDT
Date: Thu, 29 May 86 01:27 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: *DEBUG-IO*
To: COMMON-LISP@SU-AI.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA
Message-ID: <860529012732.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I didn't realize that the *xxx-IO* variables were documented to contain
synonym streams. In fact, I wish this had been disallowed.
The reason this came up is that I had an application which wanted to
temporarily use the *DEBUG-IO* for a normal interaction. I thought I
was doing the right thing by doing:
(LET ((*TERMINAL-IO* *DEBUG-IO*))
...)
but in fact I lost completely in 3600 Release 6 Common Lisp because
*DEBUG-IO* had (correctly) contained a synonym stream for
*TERMINAL-IO* and I ended up with a circular synonym stream in
*TERMINAL-IO*.
At the very least, the manual should contain a mention of this problem
at the top of p329 where it talks about why you shouldn't change
*TERMINAL-IO*.
However, more importantly, we should really have and encourage the
use of a function like the LispM's SI:FOLLOW-SYN-STREAM which
recursively dereferences a synonym stream and gives you a stream
that's safe to move around. That way, I could safely write:
(LET ((*TERMINAL-IO* (FOLLOW-SYNONYM-STREAM *DEBUG-IO*)))
...)
and you wouldn't have to have that warning about bindinging *TERMINAL-IO*.
I personally don't see any reason that binding/setting *TERMINAL-IO*
should be prohibited as long as the thing to which you bind it represents
a valid virtual terminal (whatever that means for the given operating system).
Note that there are no portable operations for creating such a virtual
terminal, but that doesn't mean that portable code shouldn't be able to
manipulate such objects when it runs across them. In particular, I think
it should be valid to shuffle the synonym-stream-deferenced contents
of *QUERY-IO*, *DEBUG-IO*, and *TERMINAL-IO* back and forth.
∂28-May-86 2243 franz!fimass!jkf@kim.Berkeley.EDU
Received: from [128.32.130.7] by SU-AI.ARPA with TCP; 28 May 86 22:43:11 PDT
Received: by kim.Berkeley.EDU (5.51/1.12)
id AA18965; Wed, 28 May 86 22:43:01 PDT
Received: from fimass by franz (5.5/3.14)
id AA27442; Wed, 28 May 86 22:34:28 PDT
Received: by fimass (5.5/3.14)
id AA01583; Wed, 28 May 86 21:32:49 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Return-Path: <fimass!jkf>
Message-Id: <8605290532.AA01583@fimass>
To: common-lisp@su-ai.arpa
In-Reply-To: Your message of Wed, 28 May 86 10:39:30 V.
<8605280139.AA00192@kurims.kyoto-u.junet>
Date: Wed, 28 May 86 21:32:43 PST
>> I would remove KEYWORD.
>> -- Taiichi
>>
'keyword' is listed in table 4-1 on page 43.
-john foderaro, franz inc.
∂29-May-86 0158 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Is &body REALLY like &rest?
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 29 May 86 01:58:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 10633; Thu 29-May-86 04:55:13 EDT
Date: Thu, 29 May 86 04:55 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Is &body REALLY like &rest?
To: Pavel.pa@XEROX.ARPA
cc: Common-lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
In-Reply-To: <860528-160852-1701@Xerox>
Message-ID: <860529045522.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 28 May 86 16:08 PDT
From: Pavel.pa@Xerox.COM
Subject: Is &body REALLY like &rest?
Another in a long series of clarifications of clarifications is
requested.
In CLtL, page 145, it says
``&body This is identical in function to &rest...''
In Guy's clarifications, it says
``145 Extend the syntax of an &body parameter to DEFMACRO to allow
writing
&body (body-var [declarations-var [doc-var]])''
so as to make it easy to call PARSE-BODY.
In CLtL, page 146, it says
``Anywhere in the lambda-list where a parameter name may appear and
where ordinary lambda-list syntax ... does not otherwise allow a list,
a lambda-list may appear in place of the parameter name.''
This allows for destructuring.
Question: Does the following DEFMACRO do destructuring or does it call
PARSE-BODY?
(defmacro foo (&rest (a b c)) (bar a b c))
The real question is whether or not the clarification introduced a
difference in the meanings of &rest and &body. One possible
interpretation is that a list after &rest does destructuring and a list
after &body implies a call to PARSE-BODY.
Which one is right?
I'm the one that suggested this extension to &BODY, so I have some remarks to
make about this...
Before saying anything, let me just remark that all of your excerpts above
are taken from the DEFMACRO section. In normal LAMBDA expressions, &BODY
is not a valid keyword; only &REST is allowed there.
We wouldn't have had both &REST and &BODY if there weren't at least some
reason for them being allowed to differ. The high-level reason for making
the distinction is that some forms, like DEFUN and LET back-indent their
bodies in some editors. eg, DEFUN indents like:
(DEFUN FOO (X Y Z)
(DECLARE (SPECIAL X))
(BAR Y Z))
The way you get things to indent that way on some systems (eg, the Lisp
Machine) is by writing:
(DEFMACRO DEFUN (NAME BVL &BODY FORMS)
...)
If you'd used &REST instead of &BODY, it would have wanted to indent like:
(DEFUN FOO (X Y Z)
(DECLARE (SPECIAL X))
(BAR Y Z))
The case where &BODY is used is in this case where there's going to be
a body. That's distinguished from something like SETQ which has no body.
So you'd write
(DEFMACRO SETQ (&REST PAIRS) ...)
rather than using &BODY to get indentation like:
(SETQ X Y
Z W
Q R)
rather than
(SETQ X Y
Z W
Q R)
Not completely by coincidence, bodies often have declarations in them, and
rest arguments seldom do. As such, there's no reason to suppose that &REST
should continue to be so similar to &BODY since it would generally be
meaningless to want to parse declarations in a SETQ. I'd vote to not let
&REST use these extra arguments.
On the other hand, when I first suggested this, I am pretty sure I suggested
doing
&BODY body-var [declarations-var [doc-var]]
rather than
&BODY (body-var [declarations-var [doc-var]])
since there's no other possible interpretation to variables following the
body variable. Not only is my original version of this extension completely
upward-compatible with existing code (since it doesn't change something that
destructured into something that does something completely different), but
it also allows better syntax for defaulting the declarations and/or doc. eg,
(DEFMACRO DEFUN-SPECIAL
(NAME VARS &BODY FORMS
(DECLARATIONS `((DECLARE (SPECIAL ,@VARS))))
(DOCUMENTATION (GUESS-SOME-DOC NAME)))
...)
might specify how to create default DECLARATIONS and DOCUMENTATION in the
absence of any explicit declarations and documentation.
∂29-May-86 0726 LOOSEMORE@UTAH-20.ARPA Apology
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 29 May 86 07:26:39 PDT
Date: Thu 29 May 86 08:24:49-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Apology
To: common-lisp@SU-AI.ARPA
Message-ID: <12210562811.21.LOOSEMORE@UTAH-20.ARPA>
It appears I have unintentionally offended a number of residents of San
Francisco with a remark in my last posting that was intended to be humorous.
That is such an old joke it never occurred to me that people would not
recognize it as such. I apologize, and in the future I will try to be more
consistent with the use of smiley faces.
-Sandra Loosemore
-------
∂29-May-86 1332 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM *DEBUG-IO*
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 29 May 86 13:31:24 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 10955; Thu 29-May-86 13:03:23 EDT
Date: Thu, 29 May 86 13:03 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: *DEBUG-IO*
To: DCP@SCRC-STONY-BROOK.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860529100713.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860529130333.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I wanted code to behave temporarily as if *debug-io* were the terminal.
Arguably, I should have done
(let ((*terminal-io* *debug-io*)
(*standard-input* (make-synonym-stream '*terminal-io*)
(*standard-output* (make-synonym-stream '*terminal-io*)
...)
...)
but if I had instead done
(let ((*standard-input* *debug-io*) (*standard-output* *debug-io*))
...)
then I would have been screwed up by code which inside my LET just did:
(let ((*standard-input* (make-synonym-stream '*terminal-io*))
(*standard-output* (make-synonym-stream '*terminal-io*)))
...)
which would have them writing on the first terminal (not my intention).
The whole point of my binding the window in the first place is that I
wanted to leave the main screen undisturbed during a debugging break.
If recursive breaks or whatever were permitted a way of realizing
that I started off on the original window, I wouldn't get the effect
I wanted. This technique is highly useful in split-screen debugging of
graphics code.
∂29-May-86 1339 NET-ORIGIN@MC.LCS.MIT.EDU Are isomorphic structures EQUAL?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86 13:39:29 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAY 86 16:23:36 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 29 MAY 86 14:24:05 EDT
Date: Thu, 29 May 86 14:23 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: Are isomorphic structures EQUAL?
To: Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860528183719.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <"860529142304.2.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>
Date: Wed, 28 May 86 18:37 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: 11 Apr 1986 16:43-EST
From: NGALL@G.BBN.COM
What happens to implementations that want to represent structures
using plain old vectors? How will EQUAL distinguish vectors from
structure-vectors?
As Rees pointed out, such an implementation would not be legal.
I checked CLtL again and found (as far as I could tell) that it IS
permissible for an implementation to represent structures as vectors, or
as numbers, packages, symbols, or any other kind of object.
I would like to change the language so that the the type of structures
(whose DEFSTRUCT doesn't use :TYPE) is disjoint from other types. I
think this is desirable both because it's a generally useful feature
(one can create new opaque types, and rely on disjointness) and because
it makes it easier to avoid implementation dependencies. It is very
easy now to unwittingly assume in a program that one's structures aren't
e.g. symbols or vectors or functions, and have the program work in 9 out
of 10 Common Lisp implementations, and then fail in a very obscure way
when moved to a new implementation.
I don't much care whether EQUAL descends into structures, as long as
it's consistent within and between implementations. I would mildly
object to having it recursively compare components because that seems to
be a violation of the data abstraction capability that structures are
supposed to provide. People who use :TYPE have to be aware that they
can have problems if they change an implementation from a transparent
one to an opaque one; not only EQUAL, but also CONCATENATE and TYPEP
will change their behavior.
Jonathan
∂29-May-86 1359 @BOETHIUS.THINK.COM:gls@AQUINAS.THINK.COM Is &body REALLY like &rest?
Received: from [192.5.104.199] by SU-AI.ARPA with TCP; 29 May 86 13:57:56 PDT
Received: from BOETHIUS.THINK.COM by Godot.Think.COM; Thu, 29 May 86 16:57:33 edt
Date: Thu, 29 May 86 16:58 EDT
From: Guy Steele <gls@Think.COM>
Subject: Is &body REALLY like &rest?
To: Pavel.pa@Xerox.COM, Common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860528-160852-1701@Xerox>
Message-Id: <860529165824.2.GLS@BOETHIUS.THINK.COM>
Date: 28 May 86 16:08 PDT
From: Pavel.pa@Xerox.COM
Another in a long series of clarifications of clarifications is
requested.
In CLtL, page 145, it says
``&body This is identical in function to &rest...''
In Guy's clarifications, it says
``145 Extend the syntax of an &body parameter to DEFMACRO to allow
writing
&body (body-var [declarations-var [doc-var]])''
so as to make it easy to call PARSE-BODY.
...
I agree with KMP's remarks on this subject. I would also like to point
out that this change is, I believe, not from the list of clarifications
but from the list of suggested changes.
--Guy
∂29-May-86 1430 DCP@SAPSUCKER.SCRC.Symbolics.COM *DEBUG-IO*
Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 29 May 86 14:29:42 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24635; Thu 29-May-86 10:02:30 EDT
Date: Thu, 29 May 86 10:07 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: *DEBUG-IO*
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>, COMMON-LISP@SU-AI.ARPA
In-Reply-To: <860529012732.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <860529100713.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 29 May 86 01:27 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
I didn't realize that the *xxx-IO* variables were documented to contain
synonym streams. In fact, I wish this had been disallowed.
The reason this came up is that I had an application which wanted to
temporarily use the *DEBUG-IO* for a normal interaction. I thought I
was doing the right thing by doing:
(LET ((*TERMINAL-IO* *DEBUG-IO*))
...)
but in fact I lost completely in 3600 Release 6 Common Lisp because
*DEBUG-IO* had (correctly) contained a synonym stream for
*TERMINAL-IO* and I ended up with a circular synonym stream in
*TERMINAL-IO*.
Shouldn't you have done
(let ((*standard-output* *debug-io*)
(*standard-input* *debug-io*))
...)
instead? It is almost always wrong to set or bind *terminal-io*.
∂29-May-86 1450 RWK@SCRC-YUKON.ARPA keyword
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 29 May 86 14:50:44 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 27214; Thu 29-May-86 05:45:35 EDT
Date: Thu, 29 May 86 05:41 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: keyword
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8605280139.AA00192@kurims.kyoto-u.junet>
Supersedes: <860529053929.0.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <860529054123.1.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
[I can't seem to mail to yuasa@kurims.kurims.kyoto-u.junet directly;
hope he receives it via the list].
Date: Wed, 28 May 86 10:39:30+0900
From: yuasa@kurims.kurims.kyoto-u.junet
Date: Fri, 23 May 86 17:34 EDT
From: Charles Hornig <Shasta!Hornig@SCRC-RIVERSIDE.ARPA>
Date: Fri, 23 May 86 05:50:43 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Is there an official 'online' list of the external lisp package
symbols implied by the Common Lisp book?
I would add COMPILATION-SPEED and remove SEQUENCEP.
I would remove KEYWORD.
-- Taiichi
I would put it back! See the list of type specifiers on
page 43.
∂29-May-86 1805 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Are isomorphic structures EQUAL?
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 29 May 86 18:05:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11421; Thu 29-May-86 18:21:31 EDT
Date: Thu, 29 May 86 18:21 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Are isomorphic structures EQUAL?
To: Jonathan A Rees <JAR@MIT-AI.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <"860529142304.2.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>
Message-ID: <860529182101.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 29 May 86 14:23 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Date: Wed, 28 May 86 18:37 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Date: 11 Apr 1986 16:43-EST
From: NGALL@G.BBN.COM
What happens to implementations that want to represent structures
using plain old vectors? How will EQUAL distinguish vectors from
structure-vectors?
As Rees pointed out, such an implementation would not be legal.
I checked CLtL again and found (as far as I could tell) that it IS
permissible for an implementation to represent structures as vectors, or
as numbers, packages, symbols, or any other kind of object.
But it's not permissible to implement them as -plain- -old- vectors.
They have to be distinguishable, at least because the language requires
structures to print differently from vectors. It's true as far as I can
see that the language allows, after (defstruct foo bar), (subtypep 'foo
'vector) to be either true or false, on an implementation-dependent
basis, and (typep (make-foo) 'vector) to be either true or false. In
my implementation, for example, the subtypep is false and the typep is
true (I wonder if that's a bug?).
I would like to change the language so that the the type of structures
(whose DEFSTRUCT doesn't use :TYPE) is disjoint from other types.
Your arguments for this are good, but on the other hand this change would
be adding substantial new constraints on implementations, wouldn't it?
Probably the reason why CLtL is so coy about exactly how structures are
implemented is to maximize implementation freedom for some reason.
∂29-May-86 1922 LOOSEMORE@UTAH-20.ARPA portability of pathnames
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 29 May 86 19:21:52 PDT
Date: Thu 29 May 86 20:20:04-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: portability of pathnames
To: common-lisp@SU-AI.ARPA
cc: jar@AI.AI.MIT.EDU
Message-ID: <12210693019.8.LOOSEMORE@UTAH-20.ARPA>
Date: Thu, 29 May 86 16:21 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
To: LOOSEMORE@UTAH-20.ARPA
Date: Tue 27 May 86 11:41:42-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
1. You can't count on being able to directly manipulate pathname
components. Explicit namestrings generally lose too.
I can believe that namestrings lose, but I think an explanation of why
pathnames lose would be very instructive. Please send a message to
common-lisp elaborating on this. Thanks.
Jonathan
The main problem with pathnames is that not all machines that you might
want to run Common Lisp on have something that corresponds to each of
the various components. A particularly brain-damaged example is the
Cray, which (as I understand it) has no directories, no file types, and
an 8-character limit on filenames. IBM's running VM/CMS aren't quite
as bad off; at least there you can have file types and several virtual
devices around, but still no directories, and of course no versions
either. Unix has directories, of course, but using a "." to delimit
the file type is simply a convention and there are no versions or things
that correspond to devices. And handling for host names under Unix is
pretty random, depending on which Unix implementation you happen to have.
The problem as I see it is with make-pathname, where you have to
explicitly give it values for each component. You can't guarantee that
a CL implementation on a brand "x" computer will be able to make sense
out of all the components, or what values are valid for each component
in that implementation or that host. The manual does say that strings are
valid for most of the components, but most operating systems have some
limitations about the lengths of the components, or what characters are
legal in filenames, or require delimiters around the components that are
totally nonsensical to other operating systems.
Here's an example from the real world. PCLS was mostly developed under
Unix, which allows the use of hyphens in filenames, which kind of crept
into the names of some of the system modules. (We use "require" to load
them during the build process; require passes the symbol-name of the
module as the :name argument to make-pathname.) When we took the code
over to VMS, we were stuck with all these references to filenames with
hyphens in them, which aren't allowed in VMS (yet -- this is supposed
to change soon). There is currently a very grody piece of code in there
that looks for hyphens in filenames and translates them to underscores.
Is make-pathname supposed to signal errors if you feed it components
that don't make sense for the given (or default) host? Or is it supposed
to try to "patch up" the problem components in some way that makes sense
for that host, such as removing or translating illegal characters or
converting a Unix directory specification with slashes into a VMS
directory specification with square brackets? Or do we just asssume
"it is an error" to supply pathname components that are illegal for the
given host?
-Sandra Loosemore
-------
∂29-May-86 2121 miller.pa@Xerox.COM Some questions
Received: from XEROX.COM by SU-AI.ARPA with TCP; 29 May 86 21:21:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 86 21:21:15 PDT
Date: 29 May 86 21:21 PDT
From: miller.pa@Xerox.COM
Subject: Some questions
To: Common-lisp@SU-AI.ARPA
Message-ID: <860529-212115-1390@Xerox>
Now that all you people and companies out there are doing all these
common-lisp compilers, I'd like to ask you some questions:
Do you transform the source to continuation passing style before
compiling?
How happy are you with this decision?
If you don't, do you do tail-recursion optimizations anyway?
If you do, do you do multiple values by calling the continuation with
multiple arguments?
Should the parameter list in a multiple-value-bind allow :optional,
:rest, etc...
When the silver book says that something has dynamic extent, it is
allowed for an implementation to provide indefinite extent, since "it is
[only] an error" to try to interact with a value whose extent has
expired. Providing indefinite extent would be a clean way for an
implementation to offer upwards compatible extensions of the language.
This would be particularly useful for catch tags.
Do you provide indefinite extent for anything for which dynamic extent
is all that's required?
Does a program have any portable way of testing whether such an
extension is available? (e.g. *features*)
Should there be?
How happy are you with packages?
In particular, for those familiar T's reified lexical environments (aka
LOCALEs), can you think of any reason for preferring packages?
Can the global scoping environment consistently be considered to simply
be the outermost lexical environment?
Can T's LOCALEs be added to the language in an upwards compatible way?
Has anybody given any thought to defining a formal semantics for
common-lisp?
Do you think there is any hope for such a thing?
What about a simple explanatory meta-interpreter (in the Scheme
tradition)?
Any common-lisp partial evaluators out there?
MarkM
∂29-May-86 2250 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM portability of pathnames
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 29 May 86 22:49:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11942; Fri 30-May-86 01:47:30 EDT
Date: Fri, 30 May 86 01:47 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: portability of pathnames
To: common-lisp@SU-AI.ARPA
In-Reply-To: <12210693019.8.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860530014715.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I completely understand and sympathize with Loosemore's problems with
pathnames, which are really problems with doing file operations in a
generic way that works on a wide variety of operating systems with
wildly varying restrictions on what their file systems can do. It's
quite a difficult problem.
The Symbolics system contains a huge amount of mechanism for dealing
with problems of this sort. The designers of Common Lisp felt that this
mechanism was hairy and unnecessary (which was incorrect) and should not
be in Common Lisp because it was too complex (which was probably
correct, at least at the time). Not having this in Common Lisp leaves
users in a bind, of course. Anyone who wanted to solve such problems
would do well to start by reading the Symbolics documentation and
talking to some Symbolics users who have used a variety of file systems.
∂29-May-86 2317 somewhere!yuasa@kurims.kurims.kyoto-u.junet Sorry, KEYWORD should be there.
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 29 May 86 23:17:28 PDT
Received: by su-shasta.arpa; Thu, 29 May 86 23:15:46 PDT
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA03021; Fri, 30 May 86 13:25:17 jst
From: yuasa@kurims.kurims.kyoto-u.junet
Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA02950; Fri, 30 May 86 13:23:38 jst
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA00627; Fri, 30 May 86 13:07:44+0900
Date: Fri, 30 May 86 13:07:44+0900
Message-Id: <8605300407.AA00627@kurims.kyoto-u.junet>
To: common-lisp@su-ai.arpa
Subject: Sorry, KEYWORD should be there.
Sorry, I was wrong. The symbol KEYWORD should be in the LISP package.
I should put it in my implementaion...
-- Taiichi
∂30-May-86 0029 RAM@C.CS.CMU.EDU Some questions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 May 86 00:29:50 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Fri 30 May 86 03:29:10-EDT
Date: Fri, 30 May 1986 03:29 EDT
Message-ID: <RAM.12210749275.BABYL@>
From: Rob MacLachlan <RAM@λλ>
To: miller.pa@XEROX.COM
Cc: Common-lisp@SU-AI.ARPA
Subject: Some questions
In-reply-to: Msg of 30 May 1986 00:21-EDT from miller.pa at Xerox.COM
Date: Friday, 30 May 1986 00:21-EDT
From: miller.pa at Xerox.COM
To: Common-lisp at SU-AI.ARPA
Re: Some questions
Now that all you people and companies out there are doing all these
common-lisp compilers, I'd like to ask you some questions:
Do you transform the source to continuation passing style before
compiling?
How happy are you with this decision?
If you don't, do you do tail-recursion optimizations anyway?
If you do, do you do multiple values by calling the continuation with
multiple arguments?
The current Spice Lisp compiler is basically a one-pass compiler which
goes directly from s-expressions to lap code. Closure variables are
implemented by patching the lap code when a reference is a closure is
discovered. The compiler is not tail-recursive, but tail-recursive
self-calls turn into branches. Support for Common Lisp features not
in Maclisp is generally poor.
Many of the Common Lisps floating around are based on Spice Lisp and
this compiler. Some exceptions are Symbolics, Lucid and KCL. The
Lucid compiler was originally based on the S1 compiler, but has
reportedly been largely rewritten. The Lucid compiler is probably
close to state of the art, but they are unlikely to talk about it in
public.
I am currently writing a new compiler for Spice Lisp which is designed
for Common Lisp and designed for portability. It will be
tail-recursive, but I am not using CPS per se. The internal
representation is not a syntax tree at all, but a flow-graph like
representation optimized for flow analysis. The idea is that most
analysis and optimization will be done using flow analysis rather than
tree walks. It is too early to tell whether this is a good idea.
Should the parameter list in a multiple-value-bind allow :optional,
:rest, etc...
What level is this question at? CLTL clearly doesn't allow any of the
lambda-list keywords in the variable list for multiple-value-bind, but
if you just macroexpand multiple-value-bind to a multiple-value-call
of a lambda, then it isn't very hard to do.
When the silver book says that something has dynamic extent, it is
allowed for an implementation to provide indefinite extent, since "it is
[only] an error" to try to interact with a value whose extent has
expired. Providing indefinite extent would be a clean way for an
implementation to offer upwards compatible extensions of the language.
This would be particularly useful for catch tags.
It is meaningless to talk about extending Common Lisp CATCH to have
indefinite extent, since it has dynamic scope. Extending
BLOCK/RETURN-FROM is a possibility, but I doubt that there's a great
deal of enthusiasm.
How happy are you with packages?
In particular, for those familiar T's reified lexical environments (aka
LOCALEs), can you think of any reason for preferring packages?
Packages cause a lot of grief, especially for new users. I think that
schemes like locales that separate values from names are cleaner, but
the historical compatibility imperative for Common Lisp probably makes
such schemes impossible. This is because the dialects with which
compatibility was desired have always confused names and values. In
any case, it is clearly too late to replace packages with anything
very different.
Can the global scoping environment consistently be considered to simply
be the outermost lexical environment?
This question doesn't make a great deal of sense in Common Lisp, since
it isn't block-structured. Some operations always manipulate the
global environment (DEFUN), others create local definitions (LET).
You can define some things globally which you can't define locally,
(types, constants), so the answer to you question may be no.
Can T's LOCALEs be added to the language in an upwards compatible way?
What do you mean by upward compatible? It would certainly be pretty
gruesome using two namespace management systems simultaneously. The
separate function, value and property-list cells would certainly hair
up any LOCALE-like scheme.
Has anybody given any thought to defining a formal semantics for
common-lisp?
Do you think there is any hope for such a thing?
We don't even have an informal definition yet...
Rob
∂30-May-86 0053 RAM@C.CS.CMU.EDU Defstruct default values
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 May 86 00:45:14 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Fri 30 May 86 03:44:34-EDT
Date: Fri, 30 May 1986 03:44 EDT
Message-ID: <RAM.12210752085.BABYL@>
From: Rob MacLachlan <RAM@λλ>
To: common-lisp@SU-AI.ARPA
Subject: Defstruct default values
I propose the following "clarification":
The default value for a defstruct slot need not be of the type
indicated in the :type slot option as long as the default is never
used.
This is obviously semantically barfucious, but is essential for anyone
who ever actually uses the :type option, since there is no way to
specify a type without specifiying a default. In many cases it is
incredibly difficult to come up with a default expression that you
can type in which will evaluate to an object of the correct type. I
have better things to do with my time than write hairy code which is
never evaluated.
Rob
∂30-May-86 0702 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA long-char, kanji
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 30 May 86 07:02:01 PDT
Received: from utokyo-relay by csnet-relay.csnet id a010279; 30 May 86 9:56 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA00256; Fri, 30 May 86 20:32:15+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA07406; Fri, 30 May 86 14:55:14+0900
Date: Fri, 30 May 86 14:55:14+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8605300555.AA07406@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida@UTOKYO-RELAY.CSNET, rwk@SCRC-YUKON.ARPA
Subject: long-char, kanji
>Date: Sun, 11 May 86 16:51 EDT
>From: "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
>Subject: The first note on kanji, sent to junet site in Jan 1986 and some reactions in japan
>In-Reply-To: <8605100330.AA08572@tansei.utyo.junet>
>Message-Id: <860511165153.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
>
Prior to reply the mail, I want to summarize my way of understanding.
The reason why I send this mail is the first mail on KANJI to common-lisp at su-ai
was not helpfull for the discussion.
This issue is also related to the relation between character data type and string data type.
CLtL says,
T > Character > string-char > standard-char
string = (array string-char (*)) = (vector string-char)
string-char type object has zero value for font and bits attributes.
standard-char type object is a character
among (ASCII) 95 characters and #\newline.
The basic idea of my draft:
add long-char, or extended-string-char.
which is needed to represent multi-byte characters.
(in the last mail, I use the word "japanese-char" instead.
I realized it was a poor choice of naming.
Here, I use "long-char" for multi-byte characters.
But the naming is temporary.)
The opinions behind the attempt to add long-char:
There are many Lisps which can not handle multi-byte characters correctly.
Many implementors and users wanted to have a common way to handle japanese characters.
Related facts (but only for information):
Each character of standard-char type have another representation in
JIS 6226 two-byte representation, which I call here regular-long-char.
Further, almost all the machines in Japan has another representation in
two-byte representation, which I call it hankaku-long-char.
Namely, "A" say, can be represented as a standard-char, regular-long-char or
hankaku-long-char. Furthermore, " " (blank character), ",", ".", "(",")"
can have three different representations !
The basic issues:
Is the long-char a subtype of character ?
Is the long-char a subtype of string-char ?
What is the relation between standard-char and long-char ?
Can a vector of long-char be a component of a string ?
If the long-char is separated from string-char, it should have font-attribute or no?
--- Selection 1 ---
make long-char be a subtype of string-char, i.e. string-char > long-char.
long-char and standard-char are disjoint.
--- Selection 2 ---
make long-char be a subtype of character type, i.e. character > long-char.
and, string-char and long-char are disjoint.
--- Selection 3 ---
make standard-char be a subtype of long-char, i.e. string-char > long-char > standard-char.
Possible consequences due to the above selections
Selection 1:
long-char (2 byte or more) and standard-char(1 byte) can be mixed in a string.
--> It seems to be very heavy for general purpose machines,
to support ELT, LENGTH etc. correctly.
And user may confuse on writing software.
--> add string-normalize function.
(string-normalize x) means,
if x is purely composed of standard-char then return x.
if x is purely composed of long-char then return x.
if x is mix-composed of subtypes of string-char,
then if all the characters of x can be representable in standard-char
then each character is converted to the representation in
standard-char,
elseif there is at least one character which can only be
representable by long-char,
then all characters are converted to long-char representation.
else error.
Selection 2:
New problem will come. That is,
Can long-char type have non-zero value for char-font and char-bits ?
--> I feel the asnwer should be "NO".
--> (vector long-char) can not be "string", because string is
(vector string-char) and string-char and long-char are assumed to be disjoint.
--> Need another type of string, say long-char-based-string,
which is parallel to string, but is disjoint to string.
I did not have a firm idea about selection yet.
At least in japan, we have to settle the matter with several computer languages
such as Cobol, Fortran, C, Ada,...
and Common Lisp.
Masayuki Ida
ida%utokyo-relay.csnet@csnet-relay.arpa
----
∂30-May-86 0848 preece%ccvaxa@gswd-vms.ARPA Defstruct default values
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 30 May 86 08:47:33 PDT
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/)
id AA01169; Fri, 30 May 86 10:47:31 CDT
Message-Id: <8605301547.AA01169@gswd-vms.ARPA>
Date: Fri, 30 May 86 10:43:23 cdt
From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Defstruct default values
Maybe I'm missing something, but the book says that the default-init
is evaluated =each time= a structure is to be constructed [emphasis
per CLtL].
> From: Rob MacLachlan
>
> I propose the following "clarification":
>
> The default value for a defstruct slot need not be of the type
> indicated in the :type slot option as long as the default is never
> used.
>
> This is obviously semantically barfucious, but is essential for anyone
> who ever actually uses the :type option, since there is no way to
> specify a type without specifiying a default. In many cases it is
> incredibly difficult to come up with a default expression that you
> can type in which will evaluate to an object of the correct type. I
> have better things to do with my time than write hairy code which is
> never evaluated.
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
∂30-May-86 0926 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Some questions
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 May 86 09:25:56 PDT
Date: Fri, 30 May 1986 12:25 EDT
Message-ID: <BROOKS.12210846917.BABYL@MIT-OZ>
From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: miller.pa@XEROX.COM, Common-lisp@SU-AI.ARPA
Subject: Some questions
In-reply-to: Msg of 30 May 1986 03:29-EDT from Rob MacLachlan <RAM at λλ>
Date: Friday, 30 May 1986 03:29-EDT
From: Rob MacLachlan <RAM at λλ>
To: miller.pa at XEROX.COM
cc: Common-lisp at SU-AI.ARPA
Re: Some questions
...
this compiler. Some exceptions are Symbolics, Lucid and KCL. The
Lucid compiler was originally based on the S1 compiler, but has
reportedly been largely rewritten. The Lucid compiler is probably
close to state of the art, but they are unlikely to talk about it in
public.
As principal author of the Lucid compiler I want to make a slight
clarification. It is certainly an intellectual descendant of the
S1 compiler, which in turn is based largely on Steele's Rabbit compiler.
However, it was written from scratch for a Common Lisp subset and I have
not even looked at the S1 code from about 6 months before coding started
in August 83. It was rather different in internal organization from the
start, and that difference has been magnified in converting it to handle
full common lisp and multiple target machines.
There will be a paper on the compiler in the ACM Lisp and Functional
Programming Symposium to be held in Cambridge in early August.
∂30-May-86 1309 franz!fimass!jkf@kim.Berkeley.EDU Re: Some questions
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 30 May 86 13:08:35 PDT
Received: by kim.Berkeley.EDU (5.51/1.12)
id AA26813; Fri, 30 May 86 13:08:35 PDT
Received: from fimass by franz (5.5/3.14)
id AA03277; Fri, 30 May 86 11:51:36 PDT
Received: by fimass (5.5/3.14)
id AA00215; Fri, 30 May 86 09:50:14 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Return-Path: <fimass!jkf>
Message-Id: <8605301750.AA00215@fimass>
To: ucbkim!Xerox.COM!miller.pa
Cc: common-lisp@su-ai.arpa
Subject: Re: Some questions
In-Reply-To: Your message of 29 May 86 21:21:00 PDT.
<860529-212115-1390@Xerox>
Date: Fri, 30 May 86 09:50:10 PST
>> Do you transform the source to continuation passing style before
>> compiling?
>> How happy are you with this decision?
>> If you don't, do you do tail-recursion optimizations anyway?
The Franz Inc. ExCL (Extended Common Lisp) compiler does not
transform to a continuation passing style before compilation. It
detects tail-recursive calls and eliminates some self-tail-recursive
calls and will soon give the user the option of eliminating non-self
tail-recursive calls on certain architectures.
Since Rob gave a description of some other compilers, I'll briefly
describe ours: It was written from scratch for Common Lisp (it is
*not* based on either the Spice Lisp compiler or the Franz Lisp
compiler). It has four passes, the first being completely machine
independent and the last completely machine dependent, with the middle
passes being somewhere in between (i.e. machine independent skeletons
with machine dependent flesh). Optimizations are done in each pass.
One feature of the ExCL compiler that distinguishes it from other
'stock hardware' compilers is that by default it generates code which
is as safe as interpreted code (with very low overhead). You can make it
unsafe (to various degrees) by adding type declarations and/or using
the optimization declaration, and this indeed helps in very frequently
executed code, but in most code the speed difference between being safe
and unsafe is imperceptible, and the benefits of being safe are tremendous.
-john foderaro, franz inc.
∂30-May-86 1401 Moon@SCRC-QUABBIN.ARPA long-char, kanji
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 30 May 86 14:00:58 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 4349; Fri 30-May-86 17:01:25 EDT
Date: Fri, 30 May 86 16:58 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: long-char, kanji
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8605300555.AA07406@ccut.u-tokyo.junet>
Message-ID: <860530165813.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here's how the character and string data types are organized in the
Symbolics system (Release 7 happened to be the version I looked at),
which supports Kanji as well as other extensions beyond the Common
Lisp standard-chars. Perhaps this can serve as a guide, as one
possible technique for extending Common Lisp characters that is
demonstrated to work.
STANDARD-CHAR is a subtype of STRING-CHAR
STRING-CHAR is a subtype of CHARACTER
FAT-CHAR is a subtype of CHARACTER
FAT-CHAR and STRING-CHAR are an exhaustive partition of CHARACTER
THIN-STRING and FAT-STRING are an exhaustive partition of STRING
THIN-STRING is (VECTOR STRING-CHAR)
FAT-STRING is (VECTOR (OR FAT-CHAR STRING-CHAR))
STANDARD-CHAR includes only the 96 characters that Common Lisp
says it includes.
STRING-CHAR includes a few dozen additional characters, and
has a representation that is 8 bits wide.
FAT-CHAR has a representation that is 28 bits wide and can
express all other characters that we support.
Note that there are slight deviations from the Common Lisp manual here.
It's not true in our system that any character whose bits and font are
zero is a STRING-CHAR, and it's not true that any STRING is a VECTOR of
STRING-CHAR. These deviations are necessary and I don't think they
depart from the spirit of the language.
CHAR-CODE-LIMIT is 65536; the other bits in a FAT-CHAR are used
for CHAR-BITS and CHAR-STYLE. CHAR-FONT-LIMIT is 1; that is,
Symbolics does not use CHAR-FONT. CHAR-STYLE is a Symbolics
extension that is used to express how the character is
portrayed (size, italicization, boldface, typeface, etc.).
Character codes are assigned dynamically. In files and for interchange,
FAT-CHARs are represented not by the binary representation used in
memory, but by a more symbolic representation involving the names of the
character set and character style. This is the default; other
representations can be used for interchange with other systems. Thus
interchange with JIS 6226 and Hankaku would be equally possible; there
is no assumption that the codes used internally and the codes used
externally are the same.
A SIMPLE-STRING is any string, thin or fat, that is a SIMPLE-ARRAY.
Since I don't know what the SIMPLE-STRING type is for, I don't know
whether allowing SIMPLE-STRINGs to be fat is good or bad.
Note: FAT-CHAR, THIN-STRING, and FAT-STRING are not actually accepted by
TYPEP (probably they ought to be), but there are predicates to test for
these types. Usually the types are invisible; string-valued functions
produce thin or fat strings as necessary, depending on the contents of
the string.
Note that the difference between thin and fat characters is completely
transparent to the user, except that you cannot store a fat character
into a thin string. There is no such thing as dual representations
of a character. In this way thin and fat characters are very analogous
to fixnums and bignums. I feel that this property is very important
for the usability of the system.
We haven't found a need for your STRING-NORMALIZE function, perhaps
just because we don't worry that much about saving storage by making
strings thin whenever possible. We do have a function ASSURE-FAT-STRING
that goes the other way; if its argument is a THIN-STRING, it makes
a new FAT-STRING that contains the same characters and returns it.
∂30-May-86 1947 FAHLMAN@C.CS.CMU.EDU long-char, kanji
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 May 86 19:41:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 30 May 86 22:41:34-EDT
Date: Fri, 30 May 1986 22:41 EDT
Message-ID: <FAHLMAN.12210959064.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Cc: fahlman@C.CS.CMU.EDU
Subject: long-char, kanji
In-reply-to: Msg of 30 May 1986 16:58-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
I like a lot of what Moon described, with a few reservations. Let me
first describe what I see as the requirements:
In trying to formulate an international standard for Common Lisp, we
clearly need to deal with this issues of extended character sets. I'm
assuming that 16 bits of character code is enough to meet everyone's
needs -- is that naive? How many thousand characters are necessary for
Japanese, and are these the same as the thousands needed for Chinese?
Are there other languages in the computer-using world that have
non-phonetic alphabets with thousands of characters?
I think that we should define some notion of fat characters and the
strings to hold them, and make sure that these are considered in all the
appropriate places as we write the rest of the spec. Fat characters and
strings should be an optional language feature: an implementation does
not have to support these, but if it does, it should do it in the
standard way. (We can specify some marker that is put on the *features*
list if and only if fat characters are supported.) I assume that any
Lisp that does not support fat characters will not do well in the
Japanese market, so there's plenty of incentive for big companies to
support this feature.
The specification of fat characters must be done in such a way that
currently legal implementations that do not support them can be left as
is; implementations that do support them must be able to do so without
penalizing users of normal non-fat strings, either in speed or storage
space.
The Symbolics spec, as described by Moon, meets these goals. However, he
says that Fat-Char and String-Char form an EXHAUSTIVE partition of
Character. This means that if an implementation supports any Char-Bit
or Char-Font bits, the fat strings must be able to accommodate these, in
addition to the longer Char-Code field. Since the Char-Code will
typically be 16 bits, it would be nice to be able to store just the
char-code in a fat string, and not make the big jump to 32 bits per
character, which is the next stop for most stock-hardare machines. I
don't know how important people feel this is, but if I were storing lots
of Japanese text in some application, I think I'd object to a 2X bloat
factor.
Two solutions are possible:
First, we could alter the type hierarchy as Moon suggests, and begin to
encourage implementations to exercise their right to have zero-length
font and bit fields in characters. A lot of us have come to feel that
these were a major mistake and should begin to disappear. (We wouldn't
legislate these fields away, just not implement them and encourage code
developers not to use them.) An implementation that does this can have
Fat-Strings with 16-bits per char, all of it Char-Code.
Alternatively, we could say that Fat-Char is a subtype of Character, with
Char-Bit and Char-Font of zero. String-Char is a subtype of Fat-Char,
with a Char-Code that fits (or can be mapped) into eight bits. A
Thin-String holds only characters that are of type String-Char. A
Fat-String holds Fat-Chars (some of which may also be String-Chars). If
you want a vector of characters that have non-zero bits and fonts, then
you use (Vector Character). I'm not sure what we do with the String
type-specifier; the two reasonable possibilities are to equate it to
Thin-String or tow the union of Thin and Fat Strings.
A SIMPLE-STRING is any string, thin or fat, that is a SIMPLE-ARRAY.
Since I don't know what the SIMPLE-STRING type is for, I don't know
whether allowing SIMPLE-STRINGs to be fat is good or bad.
For those of us without microcoded type-dispatch, Simple-String is a
very important concept. It says that you can access the Nth character
in the string simply by indexing off the address of the string by N
bytes (maybe adding some fixed offset). On a lot of machines that is
one or two instructions, and no conditionals. If Simple-Strings can be
either fat or thin, then you have to make a runtime decision about
whether to index by N bytes or 2N bytes. So it is best to reserve
Simple-String for simple thin strings and maybe add another type for
Simple-Fat-String.
-- Scott
∂30-May-86 1950 RAM@C.CS.CMU.EDU Defstruct default values
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 May 86 19:50:04 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Fri 30 May 86 22:49:46-EDT
Date: Fri, 30 May 1986 22:49 EDT
Message-ID: <RAM.12210960558.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: preece%ccvaxa@λgswd-vms.ARPA (Scott E. Preece)λ
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Defstruct default values
In-reply-to: Msg of 30 May 1986 11:43-EDT from preece%ccvaxa at gswd-vms.ARPA (Scott E. Preece)
Date: Friday, 30 May 1986 11:43-EDT
From: preece%ccvaxa at gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP at su-ai.arpa
Re: Defstruct default values
Maybe I'm missing something, but the book says that the default-init
is evaluated =each time= a structure is to be constructed [emphasis
per CLtL].
This is as opposed to being evaluated once at macroexpand time.
Although the manual doesn't say that the default expression isn't
evaluated if the slot value is supplied to the contructor, it seems
pretty pointless to evaluate the default when it isn't used. Make
that another clarification.
My message was prompted by the discovery that a certain implementation
had taken it upon itself to complain if the default was a constant and
of the wrong type. Due to the dynamic typing in Common Lisp, it is
not erroneous to have an expression which is type incorrect as long as
the expression is never evaluated. It is reasonable for a compiler to
warn about such probable type errors, but the defstruct default seems
to me to be a special case, since syntactic bogosity requires people
to specify spurious defaults.
Rob
∂30-May-86 2047 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM long-char, kanji
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 30 May 86 20:46:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12658; Fri 30-May-86 23:44:36 EDT
Date: Fri, 30 May 86 23:44 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: long-char, kanji
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12210959064.BABYL@C.CS.CMU.EDU>
Message-ID: <860530234421.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 30 May 1986 22:41 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
....
The Symbolics spec, as described by Moon, meets these goals. However, he
says that Fat-Char and String-Char form an EXHAUSTIVE partition of
Character.
I'd say that's just an implementation detail. I didn't mean to imply that
it should not be legal to introduce a third subtype of CHARACTER. I agree
with the goals, by the way.
This means that if an implementation supports any Char-Bit
or Char-Font bits, the fat strings must be able to accommodate these, in
addition to the longer Char-Code field. Since the Char-Code will
typically be 16 bits, it would be nice to be able to store just the
char-code in a fat string, and not make the big jump to 32 bits per
character, which is the next stop for most stock-hardare machines.
We considered this (and in fact partially implemented it at one time)
but felt that for our implementation the savings of storage did not
justify the extra complexity of having three subtypes of STRING instead
of two. (Actually, as it turns out there would be four subtypes: 8-bit,
32-bit, and two 16-bit subtypes, depending on whether the character has
no style or has a small code -- both special cases occur with
approximately equal frequency). I can easily understand that another
implementation that had less memory available and was more willing to
accept extra complexity might make this design decision the other way.
Having extra subtypes of CHARACTER is no problem, because just as with
fixnums and bignums the user never sees them, but any user who modifies
the contents of strings has to think about extra subtypes of STRING.
I really don't know how to deal with four subtypes of STRING in a
language standard. I'm sure you stock-hardware people will jump all
over me if I suggest that SETF of CHAR should automatically change the
representation of the string if it isn't wide enough for the character
to fit, to make the subtypes essentially invisible to users. Perhaps we
could take a hint from Common Lisp floating-point numbers, but I doubt
that that analogy is very helpful.
Two solutions are possible:
First, we could alter the type hierarchy as Moon suggests, and begin to
encourage implementations to exercise their right to have zero-length
font and bit fields in characters. A lot of us have come to feel that
these were a major mistake and should begin to disappear. (We wouldn't
legislate these fields away, just not implement them and encourage code
developers not to use them.) An implementation that does this can have
Fat-Strings with 16-bits per char, all of it Char-Code.
This would be fine. The only problem is that if the implementation later
wants to add character styles, it has to double the width of fat-strings
or add a third type of string.
Alternatively, we could say that Fat-Char is a subtype of Character, with
Char-Bit and Char-Font of zero. String-Char is a subtype of Fat-Char,
with a Char-Code that fits (or can be mapped) into eight bits. A
Thin-String holds only characters that are of type String-Char. A
Fat-String holds Fat-Chars (some of which may also be String-Chars). If
you want a vector of characters that have non-zero bits and fonts, then
you use (Vector Character). I'm not sure what we do with the String
type-specifier; the two reasonable possibilities are to equate it to
Thin-String or tow the union of Thin and Fat Strings.
I take it the way this differs from your first alternative is that there
are three subtypes of character and three subtypes of string, and you
propose to name the additional types CHARACTER and (VECTOR CHARACTER).
I don't think that's viable. The informal definition of STRING is
anything that prints with double-quotes around it. Surely any one
dimensional array of characters should qualify as a string. I don't
think it makes sense to use the name STRING for a specialized subtype of
(VECTOR CHARACTER) and have a different name for the general thing; I
think it's always cleaner to use the short name for the general thing
and qualified names for the specializations of it. Surely using STRING
to mean the union of thin and fat strings, excluding extra-fat strings,
would be confusing.
Another solution that should be permitted by the language is to have
only one representation for strings, which is fat enough to accomodate
all characters. In some environments the frequency of thin strings
might be low enough that the storage savings would not justify the extra
complexity of optimizing strings that contain only STRING-CHARs.
Stepping back a bit, what we have is an implementation-dependent
spectrum of subtypes of STRING. We need names for the most general,
which can hold any CHARACTER, and the least general, which is only
required to be able to hold STANDARD-CHARs. In addition, we need a
generic way to select from among implementation-dependent in-between
types, if there are any. If you think Common Lisp should go this far,
some deep thought is in order.
For those of us without microcoded type-dispatch, Simple-String is a
very important concept. It says that you can access the Nth character
in the string simply by indexing off the address of the string by N
bytes (maybe adding some fixed offset). On a lot of machines that is
one or two instructions, and no conditionals. If Simple-Strings can be
either fat or thin, then you have to make a runtime decision about
whether to index by N bytes or 2N bytes. So it is best to reserve
Simple-String for simple thin strings and maybe add another type for
Simple-Fat-String.
I see. Let's put this in the manual next time around.
∂30-May-86 2122 FAHLMAN@C.CS.CMU.EDU long-char, kanji
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 May 86 21:21:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 31 May 86 00:20:53-EDT
Date: Sat, 31 May 1986 00:20 EDT
Message-ID: <FAHLMAN.12210977147.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: long-char, kanji
In-reply-to: Msg of 30 May 1986 23:44-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
First, we could alter the type hierarchy as Moon suggests, and begin to
encourage implementations to exercise their right to have zero-length
font and bit fields in characters. A lot of us have come to feel that
these were a major mistake and should begin to disappear. (We wouldn't
legislate these fields away, just not implement them and encourage code
developers not to use them.) An implementation that does this can have
Fat-Strings with 16-bits per char, all of it Char-Code.
This would be fine. The only problem is that if the implementation later
wants to add character styles, it has to double the width of fat-strings
or add a third type of string.
True, but my guess is that few implementations will choose to add such a
thing. I think our current view at CMU (Rob will correct me if I'm
wrong) is that highlighting and the other things you do with "styles" is
better accomplished with some sort of external data structure that
indicates where the highlighting starts and stops. It seems wasteful to
do this on a per-character basis, and even more wasteful to tax every
character (or even just every Japanese character) with a field to
indicate possible style modification. We wouldn't make it illegal to do
this, but many implementations will go for the 2x compactness instead.
Alternatively, we could say that Fat-Char is a subtype of Character, with
Char-Bit and Char-Font of zero. String-Char is a subtype of Fat-Char,
with a Char-Code that fits (or can be mapped) into eight bits. A
Thin-String holds only characters that are of type String-Char. A
Fat-String holds Fat-Chars (some of which may also be String-Chars). If
you want a vector of characters that have non-zero bits and fonts, then
you use (Vector Character). I'm not sure what we do with the String
type-specifier; the two reasonable possibilities are to equate it to
Thin-String or tow the union of Thin and Fat Strings.
I take it the way this differs from your first alternative is that there
are three subtypes of character and three subtypes of string, and you
propose to name the additional types CHARACTER and (VECTOR CHARACTER).
I don't think that's viable. The informal definition of STRING is
anything that prints with double-quotes around it. Surely any one
dimensional array of characters should qualify as a string. I don't
think it makes sense to use the name STRING for a specialized subtype of
(VECTOR CHARACTER) and have a different name for the general thing; I
think it's always cleaner to use the short name for the general thing
and qualified names for the specializations of it. Surely using STRING
to mean the union of thin and fat strings, excluding extra-fat strings,
would be confusing.
As I read the manual, Common Lisp strings are not now allowed to contain
any characters with non-zero bit and font attributes. Arbitrary
characters can be stored in vectors of type Character, which are not
Strings and do not print with the double-quote notation. I am just
suggesting that we preserve this staus quo: the name String might be
extended to include Fat-String (in the narrow sense of Fat-String
defined above) but not to include vectors of arbitrary characters.
-- Scott
∂30-May-86 2235 FAHLMAN@C.CS.CMU.EDU Guidelines for the Standard
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 May 86 22:35:21 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 31 May 86 01:35:11-EDT
Date: Sat, 31 May 1986 01:35 EDT
Message-ID: <FAHLMAN.12210990670.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Cc: fahlman@C.CS.CMU.EDU
Subject: Guidelines for the Standard
Before we start discussing specific technical issues, we should discuss
in a general way what we want to achieve by this process. In
particular, we need to think about how much we are willing to change the
language from what is described in "Common Lisp the Language". I hope
we won't get bogged down in this discussion, but if we can set up some
explicit guidelines for ourselves now, it may eliminate a lot of
confusion about our goals later on, while we are working on technical
issues. I say "guidelines" because there is no way we can agree to a
set of strict and binding rules at this point. But at least if we have
a set of guidelines, the burden will be on the person who argues that we
should violate them in some specific case.
I have heard a variety of opinions on the issue of how closely we should
adhere to CLtL. Some have argued that the existing Common Lisp is so
terribly flawed that it should not become a standard; we would be better
off starting over. Others have argued that in the first attempt to
standardize a Lisp under ANSI and ISO, we should not deviate at all, in
incompatible ways, from the language as described in Steele. These
people argue that we should get a stable standard in place, and then do
any necessary tuning in subsequent versions.
I think that most of us are somewhere between these two extremes. Let
me set forth my own view of what our guidelines should be, which I think
a lot of people share. Comments are welcome.
-- Scott
---------------------------------------------------------------------------
Despite its imperfections, Common Lisp is already a standard. Nearly
every U.S. company with a presence in the AI market has announced some
sort of support for Common Lisp (though not always to the exclusion of
supporting other Lisps). There is similar interest in Japan among those
companies not totally committed to Prolog.
It is now our goal to turn Common Lisp from a de facto standard into an
official one. In the process, we have the opportunity to clarify those
things that are currently ambiguous (and which therefore weaken the
standard), to fix some problems that defeat the purpose of the standard
(e.g. problems that make it hard to write portable code), and to finish
defining some essential parts of the language that we left unfinished in
the rush to complete CLtL.
There are a number of implementations on the market, and many more in
the pipeline. There are many hundreds of active users, and this number
is growing very fast. A number of large software systems and AI
toolkits have been ported to Common Lisp, and again this is an
accelerating trend. All of this says that there is a very large
investment in the existing language; by the time a standard could be
approved, this investment will probably have doubled.
The existence of a large and fast-growing user community cuts two ways.
On the one hand, for every change that we consider, we must think about
not only the merits of making the change, but also the cost in terms of
code that must be changed and users who must be retrained. On the other
hand, if a change is unavoidable, the sooner we make it, the smaller the
cost.
Different kinds of changes have different kinds of costs:
Compatible extensions cost the users nothing (except that they make an
already complex language more complex). The cost is to the various
Common Lisp implementors who have to put the extension into their
respective products. If the extension is rather small, or if it will be
easy to implement (perhaps because someone supplies a public-domain
implementation of the extension), then we can consider the proposal on
its merits alone. If the extension requires some significant
implementation to make a lot of internal changes, then the threshold is
considerably higher.
In the case of true ambiguities (where implementors really have chosen
divergent interpretations, and not just where some clever fellow can
find a loophole in the language of CLtL), it is generally worthwhile to
make a clear choice, even though one group or another is going to have
to fix things. In some cases it will be appropriate to explicitly allow
both interpretations, but not where this tends to interfere with
portability of code.
Changes that affect a lot of existing user code should not be made
unless there are VERY strong reasons for doing so. Changes that would
break things in subtle ways are the worst -- something like changing the
type of NIL, for example, would break all sorts of things. Changes to
particular functions, which can be searched for by name and fixed in
straightforward ways, are not quite so bad. Changes to obscure corners
of the language that only concern a small minority of users are not so
bad, especially if the change benefits that small community and is
favored by them. For example, if there's some subtle issue about
roundoff that should be changed in order to make the number crunchers
happy, we could consider this.
In general, changes that affect only the implementors are less costly
than changes that affect all sorts of user code; there are fewer groups
that have to make changes, and they have more resources for doing so.
We must not overburden the implementors with changes or it will cause
delays and disruptions, and it could conceivably lead to a revolt, but
my guess is that a couple of dozen changes, each of which takes a
person-day or two to implement, would not be resented if the changes are
made for good reason. From the time a change is approved until the time
it becomes part of some Official Standard will be on the order of a
year. That's plenty of time to make the changes and to build and test a
new version, even for the most ponderous of companies.
There's a lot of interest in improving code portability, settling on a
workable error system, and trying to agree on an object-oriented
programming facilty (or foundation for one). If any of these goals
requires some change, that probably counts as a good reason. At this
point, mere aesthetic considerations are not sufficient to justify an
incompatible change.
∂31-May-86 1028 RWK@ELEPHANT-BUTTE.SCRC.Symbolics.COM long-char, kanji
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 31 May 86 10:28:42 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12712; Sat 31-May-86 13:26:22 EDT
Date: Sat, 31 May 86 13:21 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: long-char, kanji
To: common-lisp@SU-AI.ARPA
cc: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
In-Reply-To: <FAHLMAN.12210977147.BABYL@C.CS.CMU.EDU>
Supersedes: <860531131604.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM>,
<860531131735.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>,
<860531131827.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <860531132140.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Sat, 31 May 1986 00:20 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
True, but my guess is that few implementations will choose to add such a
thing. I think our current view at CMU (Rob will correct me if I'm
wrong) is that highlighting and the other things you do with "styles" is
better accomplished with some sort of external data structure that
indicates where the highlighting starts and stops.
I strongly disagree that this is "better". It might be "necessary"
in some environment or other, but I could argue that you're trying
to represent too much text in one string if it's really a problem
for you.
The point here is that one of the main purposes of the string data-type
is to hold text, not arbitrary sequences of characters. Character
styles are primarily part of text, not just some add-on highlighting
that's part of the presentation of that text. As part of text, they can
appear in text in editor buffers, in text files, in source files, etc.
True, sometimes they are part of the presentation, say for highlighting
a selected element in a menu. And indeed, in cases like this, we supply
the character-style information separately as either data-structure or
program-state.
It seems wasteful to
do this on a per-character basis, and even more wasteful to tax every
character (or even just every Japanese character) with a field to
indicate possible style modification. We wouldn't make it illegal to do
this, but many implementations will go for the 2x compactness instead.
It's not for all characters, unless you put all your text in
one string, which is not a very good implementation technique,
especially in an editor.
Didn't I already suggest how to avoid paying a penalty for Japanese
the last time this topic came up? Instead of a two-way partitioning
of the type space, have a three-way partitioning. ``PLUMP-STRING''
uses 16 bits to represent the characters, with default style. Most
implementations would probably NOT more than one character datatype
to implement any of these schemes, since even the hairy characters
would be an immediate datatype, but there would be a ''PLUMP-CHARACTER''
type, consisting of those characters which fit in PLUMP-STRINGs.
I believe I already explained how to use 16 bits to represent multiple
languages.
Of course, this name isn't adaquate; it should be named something
which reflects the fact that this is single-language.
More useful in the probably more common case of single-language
systems would be the equivalent technique applied to things which
are all of the same character-set (i.e. language) but with various
styles. Again, this would typically be a 16-bit-per-character
representation, although some might choose to do it with fewer.
As I read the manual, Common Lisp strings are not now allowed to contain
any characters with non-zero bit and font attributes. Arbitrary
characters can be stored in vectors of type Character, which are not
Strings and do not print with the double-quote notation.
This means they are useless, or nearly so. Please don't quote CLtL at
us, we know very well what the book says. We consider this portion of
the book to be very poorly thought out, and not suitable as a guide.
Preserving the status quo here would be a mistake. Let's not use the
book as a substitute for doing language design.
(I do consider compatibility to be a language design issue. Let
me assert that I believe compatibility is not a real problem here.
If you disagree with this, please give arguments other than just
"status quo").
I am just
suggesting that we preserve this staus quo: the name String might be
extended to include Fat-String (in the narrow sense of Fat-String
defined above) but not to include vectors of arbitrary characters.
The only way we're not in compliance is that we allow storing of
characters with non-zero bits in strings (and files). I don't see
how this can be a problem for any legal CL program.
The issue here is one of type hierarchy. Remember, MAKE-ARRAY with
:ELEMENT-TYPE (ARRAY CHARACTER) is allowed to give you back any kind
of array that can hold characters. (i.e. any supertype of character,
including T). Similarly, :ELEMENT-TYPE (ARRAY FAT-STRING-CHAR) is
allowed to give you back an array that can hold characters with bits
as well. Nowhere else in CLtL do we forbid implementations from allowing
additional types to be stored in arrays. Especially note how the
:ELEMENT-TYPE argument to OPEN is defined, with explicit mention of
:ELEMENT-TYPE CHARACTER as storing "any character".
I think the intent was to not require implementations to support
putting arbitrary characters in strings, not to forbid them from
doing so.
Note that I'm not advocating that putting characters with
bits in strings is really a good idea. If you want my honest
opinion, I don't think they should be of type CHARACTER at all.
I think they're more logically of type INPUT-GESTURE, and may
include various other bits of information, like whether you
hit the key with a feather or a hammer, or where you drew the
letter 'L' on the pad, or perhaps it wasn't a letter, but a
key on the synthesizer you keep next to your console.
But the rest of CL does not get into the business of forbidding
extensions. Let's not do it here, either. I see no reason why
CL has to forbid the inclusion of, say, diagrams in strings.
∂31-May-86 1811 FAHLMAN@C.CS.CMU.EDU long-char, kanji
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 31 May 86 18:10:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 31 May 86 21:10:38-EDT
Date: Sat, 31 May 1986 21:10 EDT
Message-ID: <FAHLMAN.12211204655.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: long-char, kanji
Didn't I already suggest how to avoid paying a penalty for Japanese
the last time this topic came up? Instead of a two-way partitioning
of the type space, have a three-way partitioning. ``PLUMP-STRING''
uses 16 bits to represent the characters, with default style.
I've got no problem with this, but it seems to be what Moon was arguing
against earlier (except that he expanded it to a four-way partitioning
and then decided that THAT was too complex).
...Please don't quote CLtL at
us, we know very well what the book says. We consider this portion of
the book to be very poorly thought out, and not suitable as a guide.
Preserving the status quo here would be a mistake. Let's not use the
book as a substitute for doing language design.
First, the reason I quoted the manual at Moon was that I read his note
as saying that any vector of type character was obviously a string. It
sounded like he was confused about the current state of things. It is
not uncommon for people whose implementations have lots of extensions to
forget where Common Lisp leaves off and the extensions begin. Even if
Moon was not confused himself (his note can be read either way), other
readers might be. When I see something like that go by, I feel that it
is important to flag the problem before the possible confusion spreads
any farther. If Moon's note had clearly indicated that he was proposing
a change or extension to our current definition of string, then I
wouldn't have quoted the book at him. (I would, however, have wondered
how you use the double-quote syntax to handle characters with bits that
have no compact printable representaiton, and characters with font
attributes that are perhaps not printable on the machine where the I/O
is occurring.)
For reasons indicated in my "proposed guidelines" message, I think that
we must start with the status quo, regardless of how stupid you or I
might think that some part of it might be. Proposals to change the
language spec are in order, but they must be very clearly labeled as
such, and the costs to users and implementors must be considered as well
as the benefits of making a change.
I guess it does no harm for Symbolics to extend Strings to hold all
kinds of characters (if the extension is internally consistent), as long
as you don't use this in portable code and as long as you don't let this
extension contaminate any function in the LISP package...but that's
another discussion.
I also agree that the current definition of characters, with their bit
and font attributes, is a total mess, but it's one that we can live
with. I'd love to make an incompatible change here and clean everything
up, but we have to move very carefully on such things. There's a lot of
code out there that might be affected. We should probably begin with a
survey of who would be screwed if char-bits and char-fonts went away.
-- Scott
∂01-Jun-86 1555 Bobrow.pa@Xerox.COM Re: Are isomorphic structures EQUAL?
Received: from XEROX.COM by SU-AI.ARPA with TCP; 1 Jun 86 15:55:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 86 15:54:55 PDT
Date: 1 Jun 86 15:54 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Are isomorphic structures EQUAL?
In-reply-to: Jonathan A Rees <JAR@ai.ai.mit.edu>'s message of Thu, 29
May 86 14:23 EDT
To: JAR@ai.ai.mit.edu
cc: Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
From: Bobrow.pa@Xerox.COM (Danny Bobrow)
Message-ID: <860601-155455-1729@Xerox>
"I would mildly object to having [EQUAL] recursively compare components
because that seems to be a violation of the data abstraction
capability
that structures are supposed to provide."
One of the proposed uses for a multi-methods in CommonLoop was to allow
methods that declared themselves as -inside- both structures, and have
the system ensure that it was called in just such a case. It would seem
that EQUAL and others are good candidates for such methods.
"I would like to change the language so that the the type of
structures
(whose DEFSTRUCT doesn't use :TYPE) is disjoint from other types."
I agree on the utility of providing easy mechanisms to suport
disjointness. Are there implementations out there that do not support
opaque types?
----- dgb:
∂01-Jun-86 2206 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA FORMAT Features
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 1 Jun 86 22:06:30 PDT
Received: from umass-cs by csnet-relay.csnet id ah05901; 2 Jun 86 1:06 EDT
Date: Sun, 1 Jun 86 16:57 EST
From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To: Common-Lisp@SU-AI.ARPA
Subject: FORMAT Features
I have been anoyed that Common Lisp has no screen manipulation primitives.
Clearly it would be nice to have a general set of Window functions, but
it would also be extremely difficult to do right. I think that
something like the following new FORMAT features would prove to be
useful. Basically I am proposing to put some of the features of Maclisp's
CURSORPOS function into FORMAT.
(1) Clear-Screen. The ~| directive used to clear the screen (window)
on some CL implementations, but last time I tried it I got PAGE
in a lozenge instead. While this behavior is useful for viewing
files it is not always desirable. If it is undesirable to
change the behavior of ~| (again) then the ~:| directive could
be used instead. If the output stream is a terminal or window
then this directive clears it. Otherwise it "outputs a page separator
character".
The following directives signal an error if the output stream cannot
support the operation.
(2) Cursor positioning. The POINT on the screen can be set with
the directive "~n,m." (That is the "period" directive.) For
example (format t "~0,0.") puts the cursor in the home position.
(format t "~V,V." x y) puts the cursor at position X, Y. One problem
with this is that the period character is hard to read on some terminals
and listings.
If period is too hard to read the directive "~:%" might be used instead.
This makes sense because the ~% directive moves the cursor to the next
line. ~n,m:% moves the cursor to anyplace on the screen.
(3) Clear-Rest-Of-Line. The directive ~J clears all characters to the
end of the line. With a precomma argument is clears that many
characters, starting at the cursor.
Alternatively this function could be assigned to "~:&".
This makes sense if one thinks of the fresh-line operation
as being primarilly to put the cursor before a blank line. The
colon can be treated as suppressing the possible preceeding carrige return.
In my experience these three functions can handle 95% of the screen
manipulations that are needed. I would also eliminate most of the
waffling in the description of the ~T tabulation directive.
Implementations should just be required to keep track of where
the cursor is. For files the implementation should keep track
of how many characters have been output since the last newline.
I can't believe its really that hard. The directive doesn't
really serve any useful purpose if people can't figure out
what it is going to do.
Each implementation still needs its own way of determining what
type of terminal is being used.
Chris Eliot
ELIOT@UMASS (CSNET)
CRE@MIT-MC (ARPA)
∂01-Jun-86 2253 REM@IMSSS CURSORPOS etc. directives
Received: from IMSSS by SU-AI with PUP; 01-Jun-86 22:53 PDT
Date: 1 Jun 1986 2253-PDT
From: Rem@IMSSS
Subject: CURSORPOS etc. directives
To: COMMON-LISP@SU-AI
ELIOT's proposed clear-to-EOL is ambiguous for bitmapped displays.
Do you clear a swath from the bitmap equal in height to the current font
height on the current line? (What is the current font if you have just
done a cursorpos without printing anything?) Or do you clear only text
that is exactly on the same line in the same font and not text from
neighboring lines that slightly overlaps the current line? Perhaps ELIOT
wants this feature only for character-only displays or other devices
that support only fixed-width fixed-height fonts in character arrays with
non-overlapping character positions, or any window that is emulating a
printing terminal with no graphics or cursor positionning (i.e. maybe
cursorpos and erase-eol are mutually exclusive on bitmapped displays)?
Actually I'd like to see somebody propose a simple set of user-interface
primitives that handle all usual kinds of terminals/displays with and
without multiple windows/panes. ELIOT's proposal is merely deficient,
not in the right direction, probably...
-------
∂01-Jun-86 2258 REM@IMSSS oops
Received: from IMSSS by SU-AI with PUP; 01-Jun-86 22:58 PDT
Date: 1 Jun 1986 2254-PDT
From: Rem@IMSSS
Subject: oops
To: COMMON-LISP@SU-AI
That last sentence should read:
ELIOT's proposal is merely deficient,
rather than not in the right direction, probably...
-------
∂02-Jun-86 0059 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU long-char, kanji
Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 2 Jun 86 00:58:44 PDT
Received: from MOSCOW-CENTRE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 34394; Mon 2-Jun-86 03:59:08-EDT
Date: Mon, 2 Jun 86 03:59 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: long-char, kanji
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12210959064.BABYL@C.CS.CMU.EDU>
Message-ID: <860602035907.5.CFRY@MOSCOW-CENTRE.AI.MIT.EDU>
In trying to formulate an international standard for Common Lisp, we
clearly need to deal with this issues of extended character sets. I'm
assuming that 16 bits of character code is enough to meet everyone's
needs -- is that naive? How many thousand characters are necessary for
Japanese, and are these the same as the thousands needed for Chinese?
Are there other languages in the computer-using world that have
non-phonetic alphabets with thousands of characters?
I was given a demo at BITSTREAM [in Cambridge]
by Phil Appley [spelling?] on their 3600 last week.
Their business is characters and fonts.
Their "character set" is about 5K characters.
Presumably most of their fonts don't even represent most of those characters,
but all of the chars are represented by some font or other that they're working on.
I don't know if they work on asian languages, but I suggest that they get
to at least review Common Lisp character standards if a change is comming.
They could probably make some insightful comments about character representation.
I can't find a net address for Phil, though he use to be at MIT.
Symbolics must have formal contact with BITSTREAM.
RLB at scrc has done a buncn of work with fonts so lets ask him too.
-------
Since people are thinking about fat characters, here's some
news from Macintosh.
The Mac allows users to change characters in editors via menu,
displaying WYSIWYG instantly. The INDEPENDENT attributes of
a character are :
font
size
bold
italic
outline
shadow [a 3d effect]
Thus any character can have any number of these.
To this set I'd like to add 2 other attributes which are very
useful in "editing" text in the newspaper sense:
underline
strike-out (each char has a horizontal line through its middle.
A whole word made up of strike-out style chars is typically still
readable, but looks crossed out. I think the idea came from PARC).
[wouldn't you love to be able to STRIKE-OUT bad code, yet leave it visable
as a negative example?]
Note that the last 6 of these require just 1 bit each.
Color is yet another issue. And grey-scaled [dejagged] fonts
might bring up some other issues, particularly with regards to
displaying on machines with different numbers of bits per pixel.
I'm not suggesting that CL standardize on all of this.
I am suggesting that the CL standard makes it not too painful
for inovators to integrate such fancy stuff in their system
which has CL as a base.
∂02-Jun-86 0140 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Guidelines for the Standard
Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 2 Jun 86 01:40:38 PDT
Received: from MOSCOW-CENTRE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 34396; Mon 2-Jun-86 04:41:22-EDT
Date: Mon, 2 Jun 86 04:41 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Guidelines for the Standard
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12210990670.BABYL@C.CS.CMU.EDU>
Message-ID: <860602044120.6.CFRY@MOSCOW-CENTRE.AI.MIT.EDU>
The existence of a large and fast-growing user community cuts two ways.
On the one hand, for every change that we consider, we must think about
not only the merits of making the change, but also the cost in terms of
code that must be changed and users who must be retrained.
First, lets not distribute the changes piecemeal, but rather as a big lump.
Maybe this should be done every September?
I can imagine many changes to CL that would make the language easier to
use for BOTH experienced and new users. The spelling of RPLACA is
my favorite example. I'm afraid Scott would call these "aesthetic".
Well, you can acuse me of being an artist.
As far as changing code, we can provide programs and data that pretty much
do the right thing to source code. There will always be glitches, of course,
but things like changing the spelling of a function and changing arg order
can be done fairly reliably with a small program and a set of data to specify the
changes. Coral recently made a major name change in our underlying software.
I wrote a function which took as args, a list of source files,
an alist of old-new name pairs, and a list of need-to-be-looked-at symbols.
The program creates new files that are the same as the old ones with
all symbols of old changed to new, and appends "???" to the end of
need-to-be-looked-at symbols. After the automatic conversion, I just searched
for "???" and did the necessary editing.
"???" was an argument, as was a suffix to be put on the names of the newly created
files.
A smarter program could distinquish symbols in function calling syntax from others,
recognize obsolete keywords, find certain reader macros, etc. All these tricks
are designed to reduce the number of need-to-be-looked-at contructs.
Such a converter program and its annual data could be kept in the yellow pages.
For obscure purposes, a converter could even go backwards using the same data.
CL could be a lot more consistent with itself.
Like, for instance, all list operators could take their primary list argument
as the first argument. Same thing for string, array and sequence operators.
A not-very-clever text modifier could even change CLtL with regards to
function spelling and arg order.
Scott is correct to point out that a constantly changing standard is
not a standard, and we do need a standard.
But a more consistent language would be easier to formally standardize,
learn, and remember. Ease of learning and remembering are key to
making any standard widely used.
Any mods will initially cost people currently involved with CL time.
The issue is, how long will it
take them to pay for themselves in people-hours versus the life-expectancy of
the OLD CL? If CL is expected to grow, we must count the hours of the yet-to-be
CL hackers in the equasion.
∂02-Jun-86 0737 shebs%utah-orion@utah-cs.arpa Re: long-char, kanji
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 2 Jun 86 07:36:54 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA06254; Mon, 2 Jun 86 08:37:41 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA28604; Mon, 2 Jun 86 08:37:37 MDT
Date: Mon, 2 Jun 86 08:37:37 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8606021437.AA28604@utah-orion.ARPA>
To: Fahlman@c.cs.cmu.edu, common-lisp@su-ai.arpa
Subject: Re: long-char, kanji
News-Path: utah-cs!@SU-AI.ARPA:FAHLMAN@C.CS.CMU.EDU
References: <FAHLMAN.12211204655.BABYL@C.CS.CMU.EDU>
Didn't you do an informal survey a while back on who actually used the
standardized bits and fonts in characters? I believe the consensus was
that nobody used them, either because an implementation didn't want to
bother, or because it was inadequate and had to be extended by those
implementations that did want more bits in characters.
stan
∂02-Jun-86 0805 FAHLMAN@C.CS.CMU.EDU Guidelines for the Standard
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Jun 86 08:05:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Jun 86 11:05:08-EDT
Date: Mon, 2 Jun 1986 11:05 EDT
Message-ID: <FAHLMAN.12211618719.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Guidelines for the Standard
This is in reply to Christopher Fry <cfry at OZ.AI.MIT.EDU>.
First, lets not distribute the changes piecemeal, but rather as a big lump.
Maybe this should be done every September?
If the whole community is participating in the discussion of what
changes to make, they will know what is coming. We can't very well
dictate to the companies when their new releases, incorporating a
particular set of changes, is to come out. Most companies can't even
dictate that to themselves.
However, changes should be grouped into discrete clusters, corresponding
to proposals for a revision to the official standard. That way, a
company can advertise a particular version of their Lisp as
"corresponding to [proposed] ANSI/ISO Common Lisp 91" or whatever.
Portable programs that run in one "Common Lisp 91" ought to run in all
others. Some companies may want to track each change as it is decided
in some internal version, and bring a new version to market as soon as
the proposal for Common Lisp N is finalized; others may want to wait
until the standard is officially approved. Presumably Common Lisp N-1
will still be available from the same company for some transition
period.
On the issue of wanting to change function names and argument orders for
greater internal consistency, I hear you, but I believe that few of the
vendors and major users would share your enthusiasm for such changes. I
could be wrong about this (mail pro and con is welcome), but that is
my current reading of the community. While one could in principle build
a program updater that makes such changes automatically, there is always
a lot of hassle during the transition, as some programs get updated and
others escape. One could also argue (weakly) that this language is
doomed to a certain amount of inconsistency in naming and argument
order. Any set of rules you establish for this is going to break down
in certain places.
(-: By the way, how else would you spell RPLACA? We kept this around
mostly as a historical monument, and any tampering would amount to
desecration. It does an ugly thing, so it should be ugly. Only wimps
use Setf of Car. But we artists are allowed to differ in matters of
aesthetic judgement. :-)
-- Scott
∂02-Jun-86 0816 FAHLMAN@C.CS.CMU.EDU long-char, kanji
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Jun 86 08:16:17 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Jun 86 11:16:07-EDT
Date: Mon, 2 Jun 1986 11:16 EDT
Message-ID: <FAHLMAN.12211620713.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: shebs%utah-orion@λutah-cs.arpa (Stanley Shebs)λ
Cc: common-lisp@SU-AI.ARPA
Subject: long-char, kanji
In-reply-to: Msg of 2 Jun 1986 10:37-EDT from shebs%utah-orion at utah-cs.arpa (Stanley Shebs)
Didn't you do an informal survey a while back on who actually used the
standardized bits and fonts in characters? I believe the consensus was
that nobody used them, either because an implementation didn't want to
bother, or because it was inadequate and had to be extended by those
implementations that did want more bits in characters.
Well, the question came up, and I don't remember anyone expressing any
fondness for Char-Bit and Char-Font, but on this list you never know if
silence means agreement or fatigue.
Let's try it again:
Suppose we were to change the standard to eliminate the Bit and Font
fields in characters. (Such fields, along with other attributes such as
"style", would be allowed as extensions, but Char-Bit and Char-Font would
no longer be part of the standard language.) Would anyone be screwed by
this? Would anyone even be unhappy about it?
This is a survey, not a formal proposal, but the result may guide our
discussions in the future.
-- Scott
∂02-Jun-86 0838 robbins%bizet.decnet@hudson.dec.com RE: FORMAT Features
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 2 Jun 86 08:38:29 PDT
Date: 2 Jun 86 11:25:00 EST
From: "BIZET::ROBBINS" <robbins%bizet.decnet@hudson.dec.com>
Subject: RE: FORMAT Features
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BIZET::ROBBINS" <robbins%bizet.decnet@hudson.dec.com>
---------------------Reply to mail dated 2-JUN-1986 01:18---------------------
>(2) Cursor positioning. The POINT on the screen can be set with
>the directive "~n,m." (That is the "period" directive.) For
>example (format t "~0,0.") puts the cursor in the home position.
>(format t "~V,V." x y) puts the cursor at position X, Y. One problem
>with this is that the period character is hard to read on some terminals
>and listings.
>If period is too hard to read the directive "~:%" might be used instead.
>This makes sense because the ~% directive moves the cursor to the next
>line. ~n,m:% moves the cursor to anyplace on the screen.
The format directives ~! ~. ~I ~W ~← are used by Dick Water's pretty printing
system. VAX Lisp V2.0 includes this pretty printer and I think that other
Lisps may be using it in the future. Please leave these directives alone.
-- Rich
Arpa: Robbins@Hudson.Dec.Com
------
∂02-Jun-86 0846 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Common Lisp Subset
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 2 Jun 86 08:45:53 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 2218; 2 Jun 86 11:44:30-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 21783; Mon 2-Jun-86 11:46:54-EDT
Date: Mon, 2 Jun 86 11:44 EST
From: mike@a
To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA
Subject: Common Lisp Subset
Cc: common-lisp@SU-AI.ARPA, ida@UTOKYO-RELAY.CSNET, mathis@USC-ISIF.ARPA
Date: Sat, 24 May 86 12:34:54+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
A Common Lisp Subset Proposal
Masayuki Ida
Assoc.Prof, Aoyama Gakuin University
Chair. Jeida Common Lisp Committee
.....
I disagree mostly with this proposal. I think a good slim subset is
important. However, I take the position that what we should leave out
is lexical scoping. This does NOT mean we should regress to dynamic
scoping, but that the subset allow only "local lexical" scoping.
I.E., free vars in lambda's or defuns MUST be globals. Code which
works under this restriction will always work under full lexical
scoping. The subset interpreter should also have this scoping.
One major win here as a subset is that you can still allow
tagbody and go. But the go targets must be known and local.
There is no implicit "throw" caused by interactions of go-targets
and lexical scoping. This is the only change to Common Lisp which
I believe will make compilation significantly easier.
I would not leave object oriented programming out of the subset.
If for example CommonLoops were adopted as a standard, I would
take the subset which omits class "class".
CommonLoops will allow programmers to extend the
subset with the features that they need in a syntactically
pleasing and upwardly compatible fashion. I.E., if the subset
doesn't include complex numbers, but a user needs them, it is
easy in commonLoops to overload the arithmetic and other
operations to do type dispatch for complex numbers. The same
is true for rationals, bignums, etc. etc.
The goal is to strip out most of the built in types which can be
constructed or provided as part of a library. Hash tables,
fill-pointer'ed arrays, extended arithmetic types, etc. all fall in
this category. Then programmers can use the object oriented feature
to build their own implementations of the needed types.
Finally, on the small machines for which this subset is intended,
declarations are crucial to performance, so they should be
allowed and exploited.
...mike
∂02-Jun-86 0905 SCHERLIS@C.CS.CMU.EDU please
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Jun 86 09:05:06 PDT
Received: ID <SCHERLIS@C.CS.CMU.EDU>; Mon 2 Jun 86 12:05:00-EDT
Date: Mon 2 Jun 86 12:04:59-EDT
From: Bill.Scherlis@C.CS.CMU.EDU
Subject: please
To: common-lisp@SU-AI.ARPA
Message-ID: <12211629622.23.SCHERLIS@C.CS.CMU.EDU>
If your mail header does not identify you or your mail address, please
include it in your message. Who is "mike@a"?
-------
∂02-Jun-86 0957 EVAN@SU-CSLI.ARPA Re: long-char, kanji
Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Jun 86 09:56:24 PDT
Date: Mon 2 Jun 86 09:53:28-PDT
From: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Subject: Re: long-char, kanji
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA, evan@SU-CSLI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>" of Mon 2 Jun 86 08:47:35-PDT
I was doing an editor a while back, and while I used normal strings for
most of the lines, I used lists of full chars for modified lines. It
was nice to be able to use the extra bits to mean things like "added since
the last screen refresh" or "deleted since..." to help the display driver
optimize.
I haven't used fonts, but only because I wasn't on a machine that could do
them. I've since moved to an Explorer, and I'm sure that now that I have
them, I'll use them. Also, now that I *have* a computer with Control,
Meta, Super and Hyper keys, I'd be very upset if I couldn't input any
combination I can type as a character.
My vote is for leaving at least bits (and probably font) in the language.
As long as string-char is there when you need efficiency, I don't see
what's wrong with having full chars as well.
Evan Kirshenbaum
evan@CSLI.STANFORD.EDU
...!ucbvax!decvax!decwrl!glacier!evan
-------
∂02-Jun-86 0958 DCP@SCRC-QUABBIN.ARPA please
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 2 Jun 86 09:58:31 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 4927; Mon 2-Jun-86 12:58:31 EDT
Date: Mon, 2 Jun 86 12:59 EDT
From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
Subject: please
To: Bill.Scherlis%C.CS.CMU.EDU@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <12211629622.23.SCHERLIS@C.CS.CMU.EDU>
Message-ID: <860602125928.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon 2 Jun 86 12:04:59-EDT
From: Bill.Scherlis@C.CS.CMU.EDU
If your mail header does not identify you or your mail address, please
include it in your message. Who is "mike@a"?
Indeed! The Symbolics mail reading program parsed it into Allegheny,
which is a local host! The recieved headers (as far as SU-AI) indicate
he is at Gold-Hill:
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 2 Jun 86 08:45:53 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 2218; 2 Jun 86 11:44:30-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 21783; Mon 2-Jun-86 11:46:54-EDT
∂02-Jun-86 1001 LOOSEMORE@UTAH-20.ARPA extending format
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 2 Jun 86 10:01:25 PDT
Date: Mon 2 Jun 86 10:59:31-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: extending format
To: common-lisp@SU-AI.ARPA
Message-ID: <12211639550.29.LOOSEMORE@UTAH-20.ARPA>
Oh no! Still more obscure options to format! Gack! :-) Seriously, I think
format is already much too complicated. Sure, you can get some amazing effects
from all of those strange options, but at the expense of making your code
totally incomprehensible to the casual reader.
Cursor positioning and screen manipulation functions should be *functions*,
and preferably "yellow pages" utilities rather than part of the language
core. I might also point out that a high-level display manipulation package
(a la curses) stands a much better chance of being portable between different
devices than does a low-level protocol. Yes, one approach to portability is
to reduce everything to a "lowest common denominator" and assume that every
device can behave roughly like a dumb VT52, but if you do that you lose on
efficiency since most devices these days are a whole lot smarter than a VT52.
-Sandra Loosemore
-------
∂02-Jun-86 1441 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU please
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 2 Jun 86 14:41:31 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 2237; 2 Jun 86 17:41:05-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 21860; Mon 2-Jun-86 17:43:27-EDT
Date: Mon, 2 Jun 86 17:40 EST
Sender: mike@a
To: Bill.Scherlis@C.CS.CMU.EDU
from: mike%acorn@oak.lcs.mit.edu
Subject: please
Cc: common-lisp@SU-AI.ARPA
Date: Mon 2 Jun 86 12:04:59-EDT
From: Bill.Scherlis@C.CS.CMU.EDU
If your mail header does not identify you or your mail address, please
include it in your message. Who is "mike@a"?
-------
Sorry about that.
I am:
Mike Beckerle
Mike%acorn@oak.lcs.mit.edu
Gold Hill Computers
Cambridge, MA.
∂02-Jun-86 1537 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM long-char, kanji
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 2 Jun 86 15:36:41 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 13860; Mon 2-Jun-86 18:33:59 EDT
Date: Mon, 2 Jun 86 18:34 EDT
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: long-char, kanji
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12211620713.BABYL@C.CS.CMU.EDU>
Message-ID: <860602183404.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 2 Jun 1986 11:16 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Suppose we were to change the standard to eliminate the Bit and Font
fields in characters. (Such fields, along with other attributes such as
"style", would be allowed as extensions, but Char-Bit and Char-Font would
no longer be part of the standard language.) Would anyone be screwed by
this? Would anyone even be unhappy about it?
Symbolics uses CHAR-BITS and does not use CHAR-FONT. Since I don't see
how a portable program could ever use CHAR-BITS, whose actual meaning is
not defined by the language standard, I don't think it would hurt our
users if CHAR-BITS were a language extension instead of a part of the
standard language. The important thing is for the standard language to
recognize that CHAR-CODE is not the only possible field, and provide the
appropriate abstractions for dealing with characters in this light (for
the most part, it does so now).
I think you will find that there are some other implementations that do
use CHAR-FONT, but I'll let them speak for themselves, if they wish to
say anything.
∂02-Jun-86 1831 RWK@ELEPHANT-BUTTE.SCRC.Symbolics.COM Common Lisp Subset
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 2 Jun 86 18:31:22 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 13986; Mon 2-Jun-86 21:28:35 EDT
Date: Mon, 2 Jun 86 21:24 EDT
From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
Subject: Common Lisp Subset
To: common-lisp@SU-AI.ARPA, mathis@USC-ISIF.ARPA
cc: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA
Supersedes: <860602212316.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>,
<860602212339.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <860602212410.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Mon, 2 Jun 86 11:44 EST
From: mike@a
One major win here as a subset is that you can still allow
tagbody and go. But the go targets must be known and local.
There is no implicit "throw" caused by interactions of go-targets
and lexical scoping. This is the only change to Common Lisp which
I believe will make compilation significantly easier.
I thought the purpose of a subset implementation was to make
it run on smaller machines, not to make it easier to write
the compiler.
I would also assume that at least a minimal amount of compatibility
would be desired. Eliminating lexical scoping eliminates an awful
lot of programs and techniques. It also means you can't look at
code and easily tell if it's legal; you have to expand every macro
that uses variables to see if it works by turning into a lambda with
a body.
I also thought a major motivation for a subset language is the so-called
"educational subset". Lexical scoping is the LAST thing I'd leave out
of an educational subset.
I would not leave object oriented programming out of the subset.
Then perhaps it should be an option.
If for example CommonLoops were adopted as a standard, I would
take the subset which omits class "class".
CommonLoops will allow programmers to extend the
subset with the features that they need in a syntactically
pleasing and upwardly compatible fashion. I.E., if the subset
doesn't include complex numbers, but a user needs them, it is
easy in commonLoops to overload the arithmetic and other
operations to do type dispatch for complex numbers. The same
is true for rationals, bignums, etc. etc.
The goal is to strip out most of the built in types which can be
constructed or provided as part of a library. Hash tables,
fill-pointer'ed arrays, extended arithmetic types, etc. all fall in
this category. Then programmers can use the object oriented feature
to build their own implementations of the needed types.
Agreed...if there is savings enough to make it worthwhile.
(I don't really know).
Finally, on the small machines for which this subset is intended,
declarations are crucial to performance, so they should be
allowed and exploited.
Yes.
∂02-Jun-86 2058 mips!pachyderm.earl@su-glacier.arpa Re: Some questions
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 2 Jun 86 20:58:37 PDT
Received: by su-glacier.arpa with Sendmail; Mon, 2 Jun 86 20:59:20 pdt
Received: from pachyderm.UUCP (pachyderm.ARPA) by mips.UUCP (4.12/4.7)
id AA10903; Mon, 2 Jun 86 18:52:04 pdt
Received: by pachyderm.UUCP (4.12/4.7)
id AA22961; Mon, 2 Jun 86 18:49:56 pdt
Date: Mon, 2 Jun 86 18:49:56 pdt
From: mips!pachyderm.earl@su-glacier.arpa (Earl Killian)
Message-Id: <8606030149.AA22961@pachyderm.UUCP>
To: glacier!franz!fimass!jkf@kim.Berkeley.EDU
Cc: ucbkim!Xerox.COM!miller.pa@su-glacier.arpa, common-lisp@su-ai.ARPA
In-Reply-To: glacier!franz!fimass!jkf@kim.Berkeley.EDU's message of Fri, 30 May 86 09:50:10 PST
Subject: Re: Some questions
From: glacier!franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
To: ucbkim!Xerox.COM!miller.pa
Cc: common-lisp@su-ai.arpa
Subject: Re: Some questions
>> Do you transform the source to continuation passing style before
>> compiling?
>> How happy are you with this decision?
>> If you don't, do you do tail-recursion optimizations anyway?
The Franz Inc. ExCL (Extended Common Lisp) compiler does not
transform to a continuation passing style before compilation. It
detects tail-recursive calls and eliminates some self-tail-recursive
calls and will soon give the user the option of eliminating non-self
tail-recursive calls on certain architectures.
Unless, you're talking about self-recursive LABELS, note that
according to a discussion on this mailing list long ago, it is not
legal to implement
(defun revappend (a b)
(if (null a)
b
(revappend (cdr a) (prog1 a (setf (cdr a) b)))))
with a branch back to the beginning of the code, because function
calls are defined in terms of symbol-function of the symbol that
happens to be the car of a form. Thus you could do
(setf (symbol-function 'foo) (symbol-function 'revappend))
and it would still be expected to call whatever is in the
symbol-function cell of revappend for recursive calls. I'm not sure I
like this (at the timeI was suggesting that DEFUN ought to provide an
implicit LABELS so that the self-recursion did the obvious thing), but
that's what was decided.
Of course, that doesn't mean it isn't possible to do tail-recursion
elimination, as long as what you're doing is jump to the contents of
the appropriate symbol-function cell value, as opposed to a simple
branch. Since your message said you only currently did
self-tail-recursion I'm assuming that's not what you're doing.
∂02-Jun-86 2114 fischer.pa@Xerox.COM Re: long-char, kanji
Received: from XEROX.COM by SU-AI.ARPA with TCP; 2 Jun 86 21:14:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 JUN 86 21:14:29 PDT
Date: 2 Jun 86 20:53 PDT
From: fischer.pa@Xerox.COM
Subject: Re: long-char, kanji
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Mon,
2 Jun 86 11:16 EDT
To: common-lisp@SU-AI.ARPA
Message-ID: <860602-211429-1134@Xerox>
In Xerox Common Lisp we have char-bits-limit and char-fonts-limit set to
zero, thus we don't use this feature and would lose no sleep over its
passing. In fact, there might be some small rejoicing but that is
beside the fact.
From discussions here I understand that the whole problem of a
programmer-friendly font system can be quite thorny. It seems the issue
before the CL community is to tentatively agree on removing a random
"wart" which was clearly a bad approach. Hopefully this will allow for
a real solution to be discussed, perhaps as part of "Common Lisp ANSI
standard extension XXX".
Xerox has its own standard called NS Characters. Xerox Lisp, Viewpoint,
Print servers, etc. have been using it happily for quite some time now.
I'd like to present the XNS Character standard's tenets but I'm not
deeply familar with them myself. Perhaps this message will stir one of
our shy folks to speak up.
(ron)
Xerox AI Systems
Palo Alto, California
∂02-Jun-86 2120 RAM@C.CS.CMU.EDU Some questions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Jun 86 21:20:41 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 3 Jun 86 00:19:54-EDT
Date: Tue, 3 Jun 1986 00:19 EDT
Message-ID: <RAM.12211763396.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: mips!pachyderm.earl@λsu-glacier.arpa (Earl Killian)λ
Cc: common-lisp@SU-AI.ARPA, glacier!franz!fimass!jkf@KIM.BERKELEY.EDU,
ucbkim!Xerox.COM!miller.pa@SU-GLACIER.ARPA
Subject: Some questions
In-reply-to: Msg of 2 Jun 1986 21:49-EDT from mips!pachyderm.earl at su-glacier.arpa (Earl Killian)
Date: Monday, 2 June 1986 21:49-EDT
From: mips!pachyderm.earl at su-glacier.arpa (Earl Killian)
Re: Some questions
Unless, you're talking about self-recursive LABELS, note that
according to a discussion on this mailing list long ago, it is not
legal to implement
(defun revappend (a b)
(if (null a)
b
(revappend (cdr a) (prog1 a (setf (cdr a) b)))))
with a branch back to the beginning of the code, because function
calls are defined in terms of symbol-function of the symbol that
happens to be the car of a form.
I would be surprised if this was really the consensus. Tail-recursive
self-calls are such a common idiom in many people's lisp styles that
it is unreasonable to prohibit them turning into a branch. I think
that a compiler should be allowed to do recursive calls however it
pleases. Any optimization of this sort can be turned off by declaring
the function NOTINLINE, forcing a full function call.
Rob
∂02-Jun-86 2232 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA New FORMAT Features
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 2 Jun 86 22:31:58 PDT
Received: from umass-cs by csnet-relay.csnet id bf15674; 3 Jun 86 1:21 EDT
Date: Mon, 2 Jun 86 18:38 EST
From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To: Common-Lisp@SU-AI.ARPA
Subject: New FORMAT Features
From: Rem@imsss
ELIOT's proposed clear-to-EOL is ambiguous for bitmapped displays.
Do you clear a swath from the bitmap equal in height to the current font
height on the current line?
I don't think there is any reasonable alternative. You might want
text and graphics to be treated as separate planes that don't affect
each other, but CL doesn't have any graphics capacity anyhow.
(What is the current font if you have just done a cursorpos without
printing anything?)
The current font is the font that would be used to print the next
character. Actually font changes are not really supported by CL,
so this is moot. Printing a character with a non-zero font field
doesn't nescessarilly change the font, does it? Does any existing
implementation use the font bits of a character to do anything like
this?
Or do you clear only text that is
exactly on the same line in the same font and not text from
neighboring lines that slightly overlaps the current line?
That would seem bizare, since presumably you want newly draw characters
to be readable.
Perhaps ELIOT
wants this feature only for character-only displays or other devices
that support only fixed-width fixed-height fonts in character arrays with
non-overlapping character positions, or any window that is emulating a
printing terminal with no graphics or cursor positionning (i.e. maybe
cursorpos and erase-eol are mutually exclusive on bitmapped displays)?
Cursorpos and erase-eol are not mutually exclusive. They interact in a
funnny way if variable sized fonts are used, but that involves using
non-CL features. A variable *width* font is OK if the cursorpos operation
is defined in terms of the width and height of the SPACE character.
(Required to be non-zero because of this.) You lose if you change
from a 12 point to a 10 point font and expect line three to be in
the same place. All of these features work together if you don't
change fonts, which you can't currently do in CL, and they can work
together anyhow if you are careful to leave enough space around
everything.
I think bit mapped displays are the only way to use a picture tube
(I own a Macintosh and no TV) but I am also concerned about the use
of dialup lines. I think it is a real shame that no one has made
ZMACS work over the chaosnet or on dialup lines. Perhaps we should
add enough primitives to CL to support the implementation of a
portable screen editor (scroll-region and insert-delete character.)
Actually I'd like to see somebody propose a simple set of user-interface
primitives that handle all usual kinds of terminals/displays with and
without multiple windows/panes.
I would too. I would rather see a Flavor system and an error system
and an iteration facility (loop macro). I think this simple set of
features does most of what we need inexpensively.
ELIOT's proposal is merely deficient,
not in the right direction, probably...
∂02-Jun-86 2329 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM tail recursion optimization
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 2 Jun 86 23:29:26 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14117; Tue 3-Jun-86 02:26:54 EDT
Date: Tue, 3 Jun 86 02:27 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: tail recursion optimization
To: ram@cmu-cs-c
cc: kmp@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI
In-Reply-To: <RAM.12211763396.BABYL@C.CS.CMU.EDU>
Message-ID: <860603022708.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
This isn't the sort of thing that is decided by a beauty contest.
As Earl pointed out, the manual is clear on this point. By the way,
the following is a valid CL function and I would be really irritated
if it didn't work...
(DEFUN FOO (X Y)
(REQUIRE 'FOO-SUPPORT) ;`Autoload' real definition of FOO!
(FOO X Y))
The definition of named functions on p59 seems to me to have pretty
clear implications in this regard.
Of course, nothing keeps you from writing a compiler which can
conditionally compile code using your optimization. However, the
default should be "off" for that switch when compiling CL programs
since it would break portable programs. If someone were to turn on
the switch, the code would not behave internally according to the
CL model, although externally it could be called by CL code since
it would be an abstraction violation of the caller to know whether
the caller was implemented using recursion or iteration. Presumably
your native SPICE:COMPILE and SPICE:COMILE-FILE functions could
observe some switch variable which CL:COMPILE-FILE and LISP:COMPILE
would bind to a safe value.
By the way, it seems to me that a CL which doesn't allow asynchronous
interrupts or multiprocessing in a shared address space should be
allowed to code-walk an expression for proof that a particular
function can be safely turned into tail-recursive call. However,
my feeling is that systems which allow me to interrupt them
and change global functions/values would be, although perhaps
technicaly within their rights to do this optimization, also likely
to confuse CL users whose model of their program might be violated
and whose "portable" experience in debugging would prove violated.
∂03-Jun-86 0002 RAM@C.CS.CMU.EDU tail recursion optimization
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Jun 86 00:02:44 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 3 Jun 86 03:02:19-EDT
Date: Tue, 3 Jun 1986 03:02 EDT
Message-ID: <RAM.12211792946.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: tail recursion optimization
In-reply-to: Msg of 3 Jun 1986 02:27-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
I am not convinced the manual is unambiguous. This another one of
the cases where your lisp culture influences your interpretation. On
a lisp machine, doing a function call always means indirecting through
the definition cell, so it is obvious to you that a self call will
indirect through the definition cell. People who are used to using
tail-recursion instead of loops will think that it is just as obvious
that a tail-recursive self call turns into a branch.
Spice Lisp, and probably other implementations, do this particular
optimization, so the manual certainly wasn't sufficiently overt about
disallowing it. We definitely need a clarification one way or the
other, and it makes a great deal of sense to me to optimize the 99.99%
case instead of the perverse one. You do need a way to inhibit this,
but as I already said, that can be done with NOTINLINE.
If this were a beauty contest then you would surely win, since Common
Lisp doesn't currently have any way to talk about this sort
of compile-time binding of global names. I think that this
deficiency should be remedied by adding a notion of block
compilation. On conventional architectures, there are huge advantages
to resolving a function reference at compile time. To me, a defun is
just a degenerate block which contains only one definition and one
entry point.
Rob
∂03-Jun-86 0151 somewhere!yuasa@kurims.kurims.kyoto-u.junet
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 3 Jun 86 01:51:40 PDT
Received: by su-shasta.arpa; Tue, 3 Jun 86 01:49:58 PDT
Received: by nttlab.ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA08743; Tue, 3 Jun 86 12:43:45 jst
From: yuasa@kurims.kurims.kyoto-u.junet
Received: by nttlab.ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA08614; Tue, 3 Jun 86 12:39:19 jst
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA00587; Mon, 2 Jun 86 12:41:57+0900
Date: Mon, 2 Jun 86 12:41:57+0900
Message-Id: <8606020341.AA00587@kurims.kyoto-u.junet>
To: Common-lisp@su-ai.arpa
Date: Fri, 30 May 1986 03:29 EDT
From: Rob MacLachlan <Shasta!RAM@λλ>
To: miller.pa@XEROX.COM
Cc: Common-lisp@SU-AI.ARPA
Subject: Some questions
In-Reply-To: Msg of 30 May 1986 00:21-EDT from miller.pa at Xerox.COM
Status: R
Date: Friday, 30 May 1986 00:21-EDT
From: miller.pa at Xerox.COM
To: Common-lisp at SU-AI.ARPA
Re: Some questions
Now that all you people and companies out there are doing all these
common-lisp compilers, I'd like to ask you some questions:
Do you transform the source to continuation passing style before
compiling?
How happy are you with this decision?
If you don't, do you do tail-recursion optimizations anyway?
If you do, do you do multiple values by calling the continuation with
multiple arguments?
......
Many of the Common Lisps floating around are based on Spice Lisp and
this compiler. Some exceptions are Symbolics, Lucid and KCL.
The current KCL compiler is a two-pass compiler which generates portable
C code. (I do not want to repeat the discussions on why C code and how it
is possible. Please refer to the KCL Report for this issue.) The main roles
of the first pass are:
1. to discriminate those lexical objects (variables, functions, blocks, and
tags) that are to be closed up in a closure from those not.
2. to collect optimization information such as type information and
reference information.
Most of the compile-time error checking is done during the first pass.
The first pass generates intermediate tree code that is similar to the
original Lisp code but is scattered with the collected information all around.
The second pass is the main pass and is responsible for the rest of the
compilation job. Tail-recursive optimization is done during the second pass.
Many other optimization hackings take place also during the second pass.
KCL is not a descendant of any other Lisp. The only reference material we
had was the draft of CLtL during the development of the first running version
of KCL (October 1983 to March 1984). (CLtL itself was not yet published at
that time.) We wrote every line of the KCL code by ourselves. (There is one
exception: we later obtained the code of RATIONALIZE from the Spice project
and used that code without changes.) Thus KCL was oriented for Common Lisp
from the very beginning. In particular, the compiler supports many Common
Lisp features: The fact that the KCL compiler is a two-pass compiler already
indicates this. (We could make it a one-pass compiler if the lexical closure
were not supported by Common Lisp.) In addition, the compiler takes care of
keyword parameters for compile-time dispatching of such functions as MEMBER
and ASSOC. It also tries to avoid creation of lexical closures in such
situations as in MAP functions, FUNCALL, and APPLY. It tries to avoid making
a list for &REST parameters in some situations, etc, etc, etc.... But it is
true that there still remains big room for improvement.
-- Taiichi
∂03-Jun-86 0152 somewhere!hagiya@kurims.kurims.kyoto-u.junet long-char, kanji
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 3 Jun 86 01:51:49 PDT
Received: by su-shasta.arpa; Tue, 3 Jun 86 01:50:08 PDT
Received: by nttlab.ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA08754; Tue, 3 Jun 86 12:44:10 jst
From: hagiya@kurims.kurims.kyoto-u.junet
Received: by nttlab.ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL
id AA08724; Tue, 3 Jun 86 12:42:41 jst
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA00200; Tue, 3 Jun 86 11:49:19+0900
Date: Tue, 3 Jun 86 11:49:19+0900
Message-Id: <8606030249.AA00200@kurims.kyoto-u.junet>
To: Common-lisp@su-ai.arpa
Subject: long-char, kanji
I think that all the discussions on extending character code
are made with the intent of defining the `international' version
of Common Lisp. The discussions, therefore, seem to keep the
pure version of Common Lisp intact and add some alien features
to it by introducing such (ugly) names as "FAT-...", "PLUMP-...",
etc.; as a result of the extension, the complex type hierarchy
of Common Lisp becomes more complex.
Complexity is sometimes unavoidable. However, I hope the simplest
solution will also be permitted, as Moon argues:
Another solution that should be permitted by the language is to have
only one representation for strings, which is fat enough to accomodate
all characters. In some environments the frequency of thin strings
might be low enough that the storage savings would not justify the extra
complexity of optimizing strings that contain only STRING-CHARs.
Common Lisp (or Lisp) is a very flexible language, and in an extreme
case, we can replace all the special forms, macros and functions of
Common Lisp with their Japanese (or Chinese or any language) counterparts
by preparing appropriate macro packages. In that case, the doc-strings
will also be written in Japanese. In such a completely Japanese
environment, it's silly to treat 8-bit characters in a special way.
I think that the discussions should be done along with how the extended
code will be used. We can consider several situations.
1. Programs written in one language (other than English) manipulate
data (characters or strings) in that language.
2. Programs written in English manipulate data in one language (other
than English).
3. Programs written in English manipulate data in more than one language
at the same time.
I myself like to program in Japanese even if the program does not
manipulate Japanese characters or strings. It's easier to device
function names in mother tongue than in a foreign language.
By the way, no one seems to stress the importance of extending symbol
names. If an extension, for example, allows simple strings to hold
only 8 bit-characters and symbol names should be simple strings, then
I completely disagree with that.
Masami Hagiya
∂03-Jun-86 0800 FAHLMAN@C.CS.CMU.EDU long-char, kanji
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Jun 86 08:00:48 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 3 Jun 86 11:00:39-EDT
Date: Tue, 3 Jun 1986 11:00 EDT
Message-ID: <FAHLMAN.12211880040.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: long-char, kanji
In-reply-to: Msg of 2 Jun 1986 12:53-EDT from Evan Kirshenbaum <evan at SU-CSLI.ARPA>
I haven't used fonts, but only because I wasn't on a machine that could do
them. I've since moved to an Explorer, and I'm sure that now that I have
them, I'll use them. Also, now that I *have* a computer with Control,
Meta, Super and Hyper keys, I'd be very upset if I couldn't input any
combination I can type as a character.
My vote is for leaving at least bits (and probably font) in the language.
As long as string-char is there when you need efficiency, I don't see
what's wrong with having full chars as well.
It is clear that each hardware/OS combination will want to provide Lisp
programs with getting at any keyboard event the user is capable of
generating
∂03-Jun-86 0815 FAHLMAN@C.CS.CMU.EDU long-char, kanji
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Jun 86 08:14:51 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 3 Jun 86 11:14:32-EDT
Date: Tue, 3 Jun 1986 11:14 EDT
Message-ID: <FAHLMAN.12211882569.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Evan Kirshenbaum <evan@SU-CSLI.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: long-char, kanji
Sorry, that last message got away. Someday someone will write a decent
mail program that is tolerant of sloppy typists...
I haven't used fonts, but only because I wasn't on a machine that could do
them. I've since moved to an Explorer, and I'm sure that now that I have
them, I'll use them. Also, now that I *have* a computer with Control,
Meta, Super and Hyper keys, I'd be very upset if I couldn't input any
combination I can type as a character.
My vote is for leaving at least bits (and probably font) in the language.
As long as string-char is there when you need efficiency, I don't see
what's wrong with having full chars as well.
It is clear that each implementation will want to provide Lisp
programs with access to any keyboard event the user is capable of
generating (and that the operating system doesn't censor). The point is
not that we want to take these away from you, but that such "input
events" are deeply unportable and that they don't have much in common
with the kinds of characters you want to use internally, pack into
strings, etc. Not only are there various bit fields to worry about, but
in an input event you might want to distinguish between "3" from the
nornal keyboard and "3" from the numeric pad, you might want a timestamp
as part of this input, and so on.
The suggestion is that hanging a "bits" field off each character is a
half-baked solution that doesn't solve the full problem for input
events, and that therefore doesn't get used in the ways we originally
anticipated. What it does do is to needlessly complicate the
representation of internal characters. The argument about "fonts" is
parallel, but this time the issue is what you send to the display to get
various effects. A font field doesn't really do the job, and it
generally makes no sense to store this in strings. I'm still pondering
whether I believe that the "style" is a legitimate part of an internal
text string or is something you do on output.
Anyway, the question was not whether you ever want to use the notion of
"fonts" and "bits" in some generic sense; the question was whether you
currently use the Char-Font and Char-Bits facility as currently defined
in the language. If people haven't made a lot of use of these in their
current form, we are free to think about whether there is some better
way of providing the comparable functionality, and how much of the
better way ought to be in the standard part of the language. If people
have made a lot of use of this facility, we're probably stuck with the
status quo, though all the implementors can conspire to make these
fields of zero length.
-- Scott
∂03-Jun-86 0830 franz!fimass!jkf@kim.Berkeley.EDU Re: tail recursion optimization
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 3 Jun 86 08:30:18 PDT
Received: by kim.Berkeley.EDU (5.51/1.12)
id AA15409; Tue, 3 Jun 86 08:30:08 PDT
Received: from fimass by franz (5.5/3.14)
id AA02763; Tue, 3 Jun 86 07:39:43 PDT
Received: by fimass (5.5/3.14)
id AA01279; Tue, 3 Jun 86 06:27:57 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Return-Path: <fimass!jkf>
Message-Id: <8606031427.AA01279@fimass>
To: common-lisp@su-ai.arpa
Subject: Re: tail recursion optimization
In-Reply-To: Your message of Tue, 03 Jun 86 03:02:00 EDT.
<RAM.12211792946.BABYL@C.CS.CMU.EDU>
Date: Tue, 03 Jun 86 06:27:53 PST
To answer earl's question: yes, a self-tail-recursive call is made
with a jump to the beginning of the function code.
I agree with Rob, this is an important optimization and 99% of the
time is it precisely what you want. I'd suggest that the Common
Lisp Standard state that within the defun of foo, there is an impliclit
(declare (inline foo))
and if the user plans on redefining foo while executing foo, it is his
burden to (declare (notinline foo)).
-john foderaro, franz inc.
∂03-Jun-86 1045 REM@IMSSS Flush bits from standard
Received: from IMSSS by SU-AI with PUP; 03-Jun-86 10:45 PDT
Date: 3 Jun 1986 1043-PDT
From: Rem@IMSSS
Subject: Flush bits from standard
To: COMMON-LISP@SU-AI
As somebody said, the semantics of bit attributes on characters is dependent
on the implementation, therefore no portable program can be written to
effectively use them. (Probably same is true of font attributes.)
In general, when a feature can't effectively be used by portable programs,
it shouldn't be considered part of the portable standard. The only exception
would be something like OPEN which is so absolutely essential to all
implementations that it's inconceivable an implementation wouldn't provide
it, and many parts of its description CAN be standardized. But in the main,
something that can't be effectively used by portable programs shouldn't
be in CLtL.
Somebody complained about the need to store arbitrary keystrokes in characters.
I don't see how this is an argument for portable bit attributes. The keyboards
on each machine are different, and thus different numbers of bit attributes
will be needed on each machine, and their semantics will be different too.
(What one machine calls META will be called EDIT on another, one machine
will have a mouse-interrupt bit while another won't. How can a program be
written to insist that HYPER-META-Q is the command for quitting a failing
grammar production in an interactive natural-language-parser program,
if my machine never heard of HYPER and doesn't have enough bits to represent
all the different commands even by juggling them around? VM/CMS doesn't even
have CONTROL or META bits, but has more than 128 basic keys on the keyboard
(treating "a" and shift-"a" i.e. "A" as different, treating <PA2> and
alt-<PA2> i.e. <fieldmark> as different, treating <PF3> and shift-<PF3>
i.e. <PF15> as different).) I vote for stripping bit&font attributes out
of the language, but would accept carefully making them as vague as possible
(just like namestrings and pathnames for OPEN) and documenting just the
hook in the manual, saying the details are implementation dependent,
so nobody will try to write portable code using the attributes directly,
but rather will put the attribute-hacking code in a separate system-dependent
file/module.
The manual should of course everywhere distinguish between where it exactly
specifies the semantics and where it merely specifies the syntax and
general idea of semantics but leaves the detailed semantics up to the
implementation, with the latter kept to the minimum.
<Opinion of REM, currently PSL programmer>
-------
∂03-Jun-86 1100 REM@IMSSS Bits for input, fonts for output
Received: from IMSSS by SU-AI with PUP; 03-Jun-86 10:59 PDT
Date: 3 Jun 1986 1057-PDT
From: Rem@IMSSS
Subject: Bits for input, fonts for output
To: COMMON-LISP@SU-AI
cc: Fahlman%C.CS.CMU.EDU@SCORE
I agree with Fahlman's message, that neither keystrokes nor fonts & presentation
is what we normally want internally in strings. I'd like to go further.
For the most part, what you want in strings is similar to what you want
in PNAMEs. Do you really want the name of some function to be [First character
plain vanilla "F", second character plain vanilla "O", third character
HYPER-META-"O"?] so that you can't access that function without somehow
getting HYPER-META-"O" actually into LISP rather than escaping to some
user-interface side-effect such as inserting ten blank lines in the
current window? Do you really want the name of some function to be
"FOO" in the Bodini font, so you have in that font or you can't access
that function? True there are some plain vanilla characters you hardly
ever want in the PNAME of an identifier/symbol, but in general you should
be able to do INTERN or STRING2ID or whatever on an arbitrary string of
whatever you consider legal characters. Any information that isn't
reasonable for coercing into a PNAME shouldn't be considered a normal part
of strings either. Use extended strings (fat strings or whatever) for
all that other cruft.
Re the Japanese person who wants to include kanji etc. in PNAMEs of symbols
(names of functions and variables mostly), I agree. Get rid of fonts
and bit attributes in PNAMEs, but allow an implementation to have fat
characters in vanilla strings and PNAMEs. -- One problem, how do you
exchange programs between ASCII-only implementations and KANJI implementations?
I don't know the answer. It may be that we can't adapt CL to handle kanji
in the right way (portably) without adding gross overhead to the ASCII-only
implementations. It may simply not be reasonable to extend CL to handle
kanji in a portable way, thus we may relegate kanji to an extension
rather than to portable CLtL. Anybody have any workable solutions??
Or should we punt on kanji this year?
-------
∂03-Jun-86 1114 @MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU type disjointness
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86 11:14:31 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 JUN 86 14:14:15 EDT
Date: Tue, 3 Jun 86 14:14:25 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: type disjointness
To: Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Thu 29 May 86 18:21 EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Message-ID: <[MX.LCS.MIT.EDU].924104.860603.JAR>
Date: Thu, 29 May 86 18:21 EDT
From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
From: JAR
I would like to change the language so that the the type of structures
(whose DEFSTRUCT doesn't use :TYPE) is disjoint from other types.
Your arguments for this are good, but on the other hand this change would
be adding substantial new constraints on implementations, wouldn't it?
Probably the reason why CLtL is so coy about exactly how structures are
implemented is to maximize implementation freedom for some reason.
Yes, that's the reason, but I'd be surprised if this freedom was really
essential. Implementing my suggestion would be easy in some
implementations and not so easy in others. Certainly a correct way to
implement this in any system would be to change VECTORP or whetever
predicate is true of structures so that it checks for structureness
before returning true. But this might be considered too costly.
However, CL already has so many types that it would surprise me if a
system existed in which adding one more was really difficult. I'd like
to hear from implementors who would have a really hard time with this --
I would probably learn something.
Jonathan
∂03-Jun-86 1531 nuyens.pa@Xerox.COM re: long-char, kanji
Received: from XEROX.COM by SU-AI.ARPA with TCP; 3 Jun 86 15:27:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 03 JUN 86 15:26:29 PDT
Date: 3 Jun 86 15:22 PDT
From: nuyens.pa@Xerox.COM
Subject: re: long-char, kanji
To: common-lisp@su-ai.ARPA
Reply-to: nuyens.pa@Xerox.COM
Message-ID: <860603-152629-1971@Xerox>
This is just a note to expand on Fischer's info about the Xerox
corporate character code standard, one of the protocols that comprise
the Printing and Network Systems. The character code standard (usually
just called NS characters) specifies character codes to represent text
fragments. This requires a mapping of character codes to graphic,
rendering and control characters together with an interchange standard
describing the legal encoding of strings of these codes.
The NS encoding is a 16-bit encoding with escapes for multibyte
characters. Single byte characters are essentially in the familiar
ISO/ANSI encoding. There are currently approximately 7100 character
codes assigned. NS is only specified as an interchange standard. In
Xerox Lisp, we use NS characters without escapes as the internal
representation. (I would discourage including escapes in internal
representations, since constant time random access is reduced to linear
scans. This is a separate decision for external representation.)
Rendering codes reside in a separate region of the character code space.
Unlike graphic character codes (e.g. STANDARD-CHAR) which determine the
information included in a text fragment, rendering codes are only used
to specify appearance. e.g. To avoid the question of whether (and how)
a text search stops at an ffl ligature when searching for "ff",
rendering characters are only included in rendered images of a document
(to send to a printer, for instance).
To give specific info about how our implementation of NS characters
addresses some of the problems mentioned recently on the list:
representation:
Strings are represented as homogeneous simple vectors of thin (8 bit) or
fat (16 bit) characters. Ignoring storage taken to represent them, the
difference between fat characters and thin characters is transparent to
the user. In particular, since we allow fat characters in symbol print
names, we use an equivalent of Ida's string-normalize function to
guarantee unique representation for hashing.
kanji:
NS includes all "JIS C 6226" graphic characters including the 6300 most
common Japanese kanji. There are also Hiragana and Katakana character
codes specified. (While there is substantial overlap with the Japanese
kanji, Chinese characters are semantically separate and their character
code assignments have not yet been published.)
type hierarchy:
Since we have char-bits-limit = char-font-limit = 1, STANDARD-CHAR is
the same as STRING-CHAR. I agree with Moon that STRING should be
(VECTOR CHARACTER) and provide specialisations (even though this is a
change from the status quo). In our applications, we do as Fahlman
suggests and use external data-structures to represent the sort of
information encoded in "styles". (It is hard to standardize which
attributes should be made part of style (some people claim "case" should
be a style bit!)).
number of character codes required:
At first glance it seems hard to imagine exceeding 16 bits. Note
however that the 7200 characters in NS don't include Chinese, Korean,
Farsi, Hindi, etc. How many times have you been *sure* that the FOO
field wouldn't be required to be larger than 16 bits?
A more detailed description of the NS character encoding is available in
XSIS 058404 available from:
Xerox Systems Institute
2100 Geng Rd.
Palo Alto, CA 94303
attn: Pam Cance (tell her you were referred by XAIS and your odds of
having any fee waived are good.)
phone: 415-496-6511
Greg Nuyens
Text, Graphics and Printing,
Xerox AI Systems
∂03-Jun-86 1538 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU type disjointness
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 3 Jun 86 15:38:12 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 2309; 3 Jun 86 18:38:15-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 22071; Tue 3-Jun-86 16:59:41-EDT
Date: Tue, 3 Jun 86 16:56 EST
From: mike@a
To: JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
Subject: type disjointness
Cc: Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
Date: Tue, 3 Jun 86 14:14:25 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Date: Thu, 29 May 86 18:21 EDT
From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
From: JAR
I would like to change the language so that the the type of structures
(whose DEFSTRUCT doesn't use :TYPE) is disjoint from other types.
Your arguments for this are good, but on the other hand this change would
be adding substantial new constraints on implementations, wouldn't it?
Probably the reason why CLtL is so coy about exactly how structures are
implemented is to maximize implementation freedom for some reason.
Yes, that's the reason, but I'd be surprised if this freedom was really
essential. Implementing my suggestion would be easy in some
implementations and not so easy in others. Certainly a correct way to
implement this in any system would be to change VECTORP or whetever
predicate is true of structures so that it checks for structureness
before returning true. But this might be considered too costly.
However, CL already has so many types that it would surprise me if a
system existed in which adding one more was really difficult. I'd like
to hear from implementors who would have a really hard time with this --
I would probably learn something.
Jonathan
∂03-Jun-86 1601 mips!pachyderm.earl@su-glacier.arpa tail recursion optimization
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 3 Jun 86 16:01:46 PDT
Received: by su-glacier.arpa with Sendmail; Tue, 3 Jun 86 16:02:19 pdt
Received: from pachyderm.UUCP (pachyderm.ARPA) by mips.UUCP (4.12/4.7)
id AA23650; Tue, 3 Jun 86 15:04:22 pdt
Received: by pachyderm.UUCP (4.12/4.7)
id AA06981; Tue, 3 Jun 86 15:02:11 pdt
Date: Tue, 3 Jun 86 15:02:11 pdt
From: mips!pachyderm.earl@su-glacier.arpa (Earl Killian)
Message-Id: <8606032202.AA06981@pachyderm.UUCP>
To: glacier!RAM@C.CS.CMU.EDU
Cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: Rob MacLachlan's message of Tue, 3 Jun 1986 03:02 EDT
Subject: tail recursion optimization
Date: Tue, 3 Jun 1986 03:02 EDT
From: Rob MacLachlan <glacier!RAM@C.CS.CMU.EDU>
If this were a beauty contest then you would surely win, since Common
Lisp doesn't currently have any way to talk about this sort
of compile-time binding of global names. I think that this
deficiency should be remedied by adding a notion of block
compilation.
Common Lisp certainly does have a way to talk about this sort of
thing. My original question to the Common-Lisp mailing list
(2 years ago?), was something like
"Is (DEFUN foo (a...) body) equivalent to
(SETF (SYMBOL-FUNCTION 'foo) #'(LAMBDA (a...) body))
or
(SETF (SYMBOL-FUNCTION 'foo) (LABELS ((foo (a...) body)) #'foo))
?"
LABELS also accomodates block compilation easily. The only question
is whether it is used by DEFUN or not. Various people objected to
this. The only argument I can remember after this long a time (there
are archives of this stuff of course) is that TRACE wouldn't work on
functions that branched back because TRACE works by using the
SYMBOL-FUNCTION cell. Of course, TRACE could be fixed instead of
breaking DEFUN, but that's not how things were left...
P.S. I think DEFUN ought to be defined in the manual by LISP code such
as the above to avoid ambiguity. Implementations will of course add
cruft to remember old definitions and issue warnings and stuff, but
the basic operation should be well-defined in terms of simpler LISP
code.
∂03-Jun-86 2348 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Guidelines for the Standard
Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86 23:48:35 PDT
Received: from KAREN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 34660; Wed 4-Jun-86 02:47:11-EDT
Date: Wed, 4 Jun 86 02:48 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Guidelines for the Standard
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12211618719.BABYL@C.CS.CMU.EDU>
Message-ID: <860604024822.2.CFRY@KAREN.AI.MIT.EDU>
One could also argue (weakly)
No, probably strongly!
that this language is
doomed to a certain amount of inconsistency in naming and argument
order. Any set of rules you establish for this is going to break down
in certain places.
Yeah but we could be a lot more consistent than we are now.
I meant only to eliminate unnecessary inconsistency such as
nth takes it's index as the first arg and elt takes its
index as the 2nd arg.
[Below I propose flushing NTH which solves this particular inconsistency.]
(-: By the way, how else would you spell RPLACA? We kept this around
mostly as a historical monument, and any tampering would amount to
desecration.
Here in Boston we have a place called the Computer Museum.
I'm sure we could find an honorable resting place for RPLACA there.
It does an ugly thing, so it should be ugly.
Well, you've got a point. Frequently new cars are uglier than old ones
so replacing your old car can be ugly.
Only wimps
use Setf of Car. But we artists are allowed to differ in matters of
aesthetic judgement. :-)
Touche! I forgot that ART can be used to argue both sides of any dispute.
......
I'd flush both rplaca AND car.
(setf (elt foo) new-value)
where the 2nd arg to elt defaults to 0.
And, in case you're wondering about rplacd...
(setf (rest foo) new-value)
I'd extend rest to take an optional 2nd arg of index
so that we could flush cdr AND nthcdr. This new arg to
rest defaults to 1. [A value of 0 just returns the first arg]
I'd also flush the rest of the car and cdr derived fns,
as well as first -> tenth and nth [use elt instead].
The above proposals eliminate 42 functions from CL,
whose functionality is pretty easily accomodated by
the addition of 1 optional arg to each of 2 existing
functions. [Readers of Hitchikers Guide to the Galaxy can now
infer the question to which the answer is 42.]
If you tell me that CADAR functionality is essential to CL,
then I'd propose that elt be able to take a list of
integers which specifies a "list-path" to get to any
arbitrary element or cons of a [nested] list.
With this notation, we could flush REST too,
[my list-path notation allows the specification of
tails of lists as well]
but I'm not sure I'm willing to go to THAT extreme.
[Though it would bring the total up to 43].
elt vs nth as far as efficency is concerned can be
fixed with a declaration, when you really care.
A smart compiler can turn (elt foo 1) into the same code
as (cadr foo). Notice there is exactly 1 character difference
in length for those of you concerned about typing.
Getting just a little fancier, a negative index to
elt or rest could index from the END of the list instead of
the beginning. Thus
(rest foo -1) is equivalent to (last foo) .
[I'm up to 44]
These negative indicies have the disadvantage of missing
a common error check, like for instance, when
you're in a loop decrimenting the index and using that
index in a call to NTH, you'd like something to tell you
if your index goes illegally below 0. This could be
fixed by having an optional 3rd arg PERMIT-NEGATIVE-INDEX?
which defaults to t, and is primarily used by the compiler.
But you still need to check ranges for too positive or too
negative anyway so maybe this point is moot.
......
As was pointed out during the subset discussion recently
[I think by RAM], eliminating these forty odd functions
would not decrease the size of an implementation of CL
by 44/620. It would make it a little smaller, but
it would make it easier for people to learn to code in CL
and, even more dramatically, make it easier to read CL.
There are other redundancies and inconsistencies in
CL of negative value. The above is just an example of
the kinds of mods that could be made. Do I hear 45?
ps: I've already implemented all the stuff I've proposed
cutting so this isn't saving me any work.
∂03-Jun-86 2357 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU long-char, kanji
Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86 23:56:49 PDT
Received: from KAREN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 34661; Wed 4-Jun-86 02:55:32-EDT
Date: Wed, 4 Jun 86 02:56 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: long-char, kanji
To: Fahlman@C.CS.CMU.EDU, evan@SU-CSLI.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12211882569.BABYL@C.CS.CMU.EDU>
Message-ID: <860604025644.3.CFRY@KAREN.AI.MIT.EDU>
Anyway, the question was not whether you ever want to use the notion of
"fonts" and "bits" in some generic sense; the question was whether you
currently use the Char-Font and Char-Bits facility as currently defined
in the language.
Coral has not yet used char-font and char-bits.
If people haven't made a lot of use of these in their
current form, we are free to think about whether there is some better
way of providing the comparable functionality, and how much of the
better way ought to be in the standard part of the language.
I'd like to see a convention for input events that could easily
accomodate a mouse. My maximal mouse has 15 keys and 6 degrees of
motion, with 1 mouse for each hand, so three buttons plus X and Y
won't do.
∂04-Jun-86 0711 FAHLMAN@C.CS.CMU.EDU Guidelines for the Standard
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Jun 86 07:11:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Jun 86 10:11:31-EDT
Date: Wed, 4 Jun 1986 10:11 EDT
Message-ID: <FAHLMAN.12212133246.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Guidelines for the Standard
In-reply-to: Msg of 4 Jun 1986 02:48-EDT from Christopher Fry <cfry at OZ.AI.MIT.EDU>
To: Christopher Fry <cfry at OZ.AI.MIT.EDU>
Well, we all realize that there are a lot of redundant forms here, and
that we could get away with any of several subsets. ELT would not be
the one I would choose to keep, if I had to choose, but that's not
really the point. The point is that people wanted these kept for
compatibility with older Lisps (and with older Lisp programmers). I
don't think that many people maintaining large bodies of code would
share your enthusiasm for a radical simplification at this point.
I wouldn't mind seeing some style guidelines that point to certain of
these forms as the ones to use in new code, so that in a few years we
can get rid of the ones not in favor, but I don't think that such
guidelines ought to be part of a specification document. Maybe we need
a companion document of style guidelines, though I suspect that getting
people to agree on these would be pretty bloody.
-- Scott
∂04-Jun-86 0720 NGALL@G.BBN.COM Re: Are isomorphic structures EQUAL?
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 4 Jun 86 07:20:02 PDT
Date: 4 Jun 1986 10:19-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Are isomorphic structures EQUAL?
From: NGALL@G.BBN.COM
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 4-Jun-86 10:19:08.NGALL>
In-Reply-To: <860528183719.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Are isomorphic structures EQUAL?
....
There will be no way to do a component-wise test (using EQUAL on each
component) on two structures unless one writes a structure-specific
equality predicate.
Therefore, I propose that two structures of the same type that are
created by DEFSTRUCT (regardless of the :TYPE option) be tested for
equality component-wise and that the CLtL make this clear.
Until then, she can get by with EQUALP (since her structures don't
conatin strings, floats, etc.).
I don't understand this. I can't find anything in the manual that says
that EQUALP behaves differently than EQUAL for structures. Actually I
can't find anything in the manual that says anything at all about the
behavior of either EQUAL or EQUALP on structures.
It may be that by coincidence the two implementations you mentioned in
your message both compare components of structures (with the default
defstruct options, especially no :TYPE) in EQUALP, and do not compare
components of structures in EQUAL, but I don't think the Common Lisp
manual says that all implementations have to do that.
The definition of EQUAL on pg. 80 says, "Certain objects that have
components are EQUAL if they are of the of the same type and
corresponding components are EQUAL." Following this line is an
enumeration of these "certain objects".
The definition of EQUALP on the next page has an identical line
(substituting EQUALP for EQUAL) EXCEPT it omits the word "certain". I
(and apparently the two implementations that I mentioned) interpret
this to mean that EQUALP does behave differently from EQUAL, in that
EQUALP performs a component-wise equality check on ALL objects that
are defined to have componentsin CLtL. It just so happens that
objects defined by defstruct are the only objects not enumerated in
the definition of EQUAL that would be covered by EQUALP.
I agree that CLtL isn't explicit about the behavior of EQUAL and
EQAULP on structures, but I think the behavior of EQUAL and EQUALP in
the two implementations is due their interpreting the relevant
definitions as I did above, not to coincidence. I am curious how
other implementations defined EQUAL and EQUALP's behavior on
structures. I just tried it on KCL and they behave identically: both
do a component-wise test (this is the behavior I personally prefer).
I'd say that this is a fairly major ambiguity in CLtL and should be
clarified as soon as possible (even if just informally).
-- Nick
∂04-Jun-86 1210 LOOSEMORE@UTAH-20.ARPA a standardization proposal
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 4 Jun 86 12:10:23 PDT
Date: Wed 4 Jun 86 11:20:28-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: a standardization proposal
To: common-lisp@SU-AI.ARPA
Message-ID: <12212167652.9.LOOSEMORE@UTAH-20.ARPA>
It seems like most of the ongoing problems with Common Lisp derive from
places in the manual where there has been some effort made to standardize
inherently non-portable features. The net result is that many
implementations are forced to provide support for functions that are
essentially useless, but the standard is still too weak to enforce that
programs that attempt to use these features be portable.
The business about character bits and font is a perfect example: any
program that uses them is potentially non-portable anyway, so it's
rather silly to insist that every implementation provide functions
for dealing with them.
As a solution to this, I would like to see things in Common Lisp divided
into two distinct categories: (1) things that *every* implementation
*must* provide to call itself "Common Lisp"; and (2) things that an
implementation need not provide, but for which a standardized interface is
desirable. Moreover, I would like to see things in category (2) given
standardized names which can be present in *features*, so that you can
readily tell whether or not the implementation supports that feature.
So, if somebody has a proposal for handling generalized input events (or
Kanji characters or screen manipulation functions or whatever) that is
generally acceptable to others interested in implementing such a feature,
it could be given a standard name and documented in the manual as being
optional. Implementors that aren't interested in it, or that can't
support it given the constraints of the operating system environment or
whatever, are under no obligation to provide it. Programs that depend
on the feature can test for its presence before using it.
This approach would also be useful for defining various levels of CL
subsets. For example, does an implementation designed for educational
use on microcomputers really need to support complex numbers and four
kinds of floats? Removing complex numbers from the language core and
making it an optional feature would at least give us a standardized way of
talking about what things a given implementation does and doesn't support.
I believe that there was a similar proposal to break the language up
into a "core" plus various modules around at the time of the Swiss Cheese
edition of the manual, but it was removed for lack of interest. Are
people still of the opinion that this is a useless idea, or is there
more motivation for it now that we have a bit more experience with the
language?
-Sandra Loosemore
-------
∂04-Jun-86 1416 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU a standardization proposal
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 4 Jun 86 14:15:55 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 2364; 4 Jun 86 17:15:49-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 22384; Wed 4-Jun-86 17:17:38-EDT
Date: Wed, 4 Jun 86 17:14 EST
Sender: mike@a
To: LOOSEMORE@UTAH-20.ARPA
From: mike%acorn@oak.lcs.mit.edu
Subject: a standardization proposal
Cc: common-lisp@SU-AI.ARPA
Date: Wed 4 Jun 86 11:20:28-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
.....
As a solution to this, I would like to see things in Common Lisp divided
into two distinct categories: (1) things that *every* implementation
*must* provide to call itself "Common Lisp"; and (2) things that an
implementation need not provide, but for which a standardized interface is
desirable. Moreover, I would like to see things in category (2) given
standardized names which can be present in *features*, so that you can
readily tell whether or not the implementation supports that feature.
.....
I believe that there was a similar proposal to break the language up
into a "core" plus various modules around at the time of the Swiss Cheese
edition of the manual, but it was removed for lack of interest. Are
people still of the opinion that this is a useless idea, or is there
more motivation for it now that we have a bit more experience with the
language?
I think this is a good idea.
-Sandra Loosemore
-------
I have heard that in Europe there is sentiment to have a
"core" common lisp and several rings round it to add functionality.
This is in reaction to all the manufacturers having their own dialect
of "foobar-Common-Lisp", none of which can really claim to be since
there is no real agreement other than a vague similarity to something
described in CLtL.
...mike beckerle
Gold Hill Computers
∂05-Jun-86 0623 @MCC.ARPA:krall%amethyst%mcc-pp@mcc a standardization proposal
Received: from MCC.ARPA by SU-AI.ARPA with TCP; 5 Jun 86 06:22:57 PDT
Received: from mcc-pp by MCC.ARPA with TCP; Thu 5 Jun 86 08:22:42-CDT
Posted-Date: Thursday, 5 June 1986, 08:24-CDT
Message-Id: <8606051324.AA19847@mcc-pp>
Received: from amber by mcc-pp (4.12/RKA.860601)
id AA19847; Thu, 5 Jun 86 08:24:00 cdt
Date: Thursday, 5 June 1986, 08:24-CDT
From: <krall%amethyst%mcc-pp@mcc (Ed Krall)>
Sender: KRALL%mcc-pp@mcc
Subject: a standardization proposal
To: common-lisp%SU-AI.ARPA@mcc
Cc: guzman%mcc-pp@mcc, hall%mcc-pp@mcc
I have been monitoring the portability issue for some
time and have been dismayed by the subset contingent.
The Lisp community must learn from Ada: subsets are
useful for testing, training, teaching, but not for
portability.
A program is fully portable
I. if every symbol used in the program is instantiated
(1) in the "Common-Lisp-only" package, or
(2) in the package associated with program
itself, and
II. if the program uses only the standard readtable
or one defined by the program itself, and
III. if it was written with porting to many systems as
a goal, and
IV. if "everything else is OK!".
Thus no "compatible"
extensions may be used, and -- most importantly -- there
is no other package of symbols visible in the program.
Every symbol used is in (1) or (2) and everything not in
(1) and (2) is completely shadowed.
Implication: if I want a specific mathematical function
in my programs, I MUST reproduce ALL of the code of the
function and everything it depends on and put it
into my program! Even then I may not be able to
reproduce the environment successfully.
Implication #2: the Common Lisp packages must be identical
throughout the target world, containing no more nor no
less than any other Common Lisp package if the program is
to be ported.
I don't believe the portability impact on Lisp is any
different than that of C or Pascal or Ada; it's just that
Lisp programmers take advantage of "goodies". In C the
program is delivered with its library. So too in Lisp.
I urge the Common Lisp community to reject the pleas for
subset definition.
-Ed Krall
Microelectronics and Computer Technology Corporation
9430 Research Blvd.
Austin, Texas 78759
(512) 834-3406
ARPA: krall@mcc.arpa
UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall
∂05-Jun-86 0820 REM@IMSSS I claim subsetting doesn't kill portability
Received: from IMSSS by SU-AI with PUP; 05-Jun-86 08:20 PDT
Date: 5 Jun 1986 0817-PDT
From: Rem@IMSSS
Subject: I claim subsetting doesn't kill portability
To: COMMON-LISP@SU-AI
I agree with Krall that if the LISP or whatever standardly-named package
doesn't contain all of the CL language (or the subset) and exactly that
with nothing else, you have trouble with portability. Krall seems to be
saying there's no way to have the LISP package contain exactly the subset
and have the LISP package contain exactly fullblown CL. Well, with loading
of compiled files into an existing LISP package and with multiple startup
shell scripts (CMS EXEC files etc.), I claim it is possible. You simply
put that part of the LISP system which absolutely must be handcoded or
cross-compiled in the kernel, and put all the rest in runtime-loadable
(binary program space) modules. You can then have well-defined supersets
of the kernel which are subsets of the fullblown system (or if you want,
kernel-supersets which are NOT subsets of CL). You have a different shell
script for each well-defined (documented) superset of the kernel. The method
can be (1) actually load in all the extra modules each time the user boots
a new user environment ("core image"), (2) simply install autoload properties
for all the functions in all the additional modules that are to be made
available, or (3) pre-load all the actual modules or autoload properties
and save the core image or savefile on the disk to be quickly restored
by any user. Installation of CL on a given system can then consist of
(a) building the kernel, (b) compiling all the loadable modules, (c)
creating all the core-images of savefiles if option (3) was used, (d)
setting up all the shell scripts for the various supersets of the kernel,
(e) making documentation for the CL available in hardcopy or online,
including definition of the various subsets available, and (f) announcing
the various shell scripts available, including telling which CL subsets
(kernel supersets) correspond to which shell scripts.
Porting a program written in an official CL-subset (kernel-superset)
from one machine to another then becomes simple: (aa) FTP the source,
(bb) read the comment at the top of the source that tells which subset
it needs, (cc) check the annoncements of shell scripts to see which one
corresponds to that subset, (dd) run it.
That algorithm doesn't work if the target machine didn't have the particular
subset on which the original program was developed and which it needed
to run, but the same would be true if the target machine didn't have CL
at all, as would likely be the case if it was a small machine and CL
didn't have subsets defined, so that argument isn't a refutation to my
claim. Anybody able to find a sound refutation/rebuttal to my claim that
Krall's view is wrong?
-------
∂06-Jun-86 0116 somewhere!yuasa@kurims.kurims.kyoto-u.junet some questions
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 6 Jun 86 01:16:35 PDT
Received: by su-shasta.arpa; Fri, 6 Jun 86 01:14:51 PDT
Received: by nttlab.ntt.junet (4.12/4.7JC-7) with TCP
id AA00370; Thu, 5 Jun 86 16:28:23 jst
From: yuasa@kurims.kurims.kyoto-u.junet
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA00541; Thu, 5 Jun 86 15:11:25+0900
Date: Thu, 5 Jun 86 15:11:25+0900
Message-Id: <8606050611.AA00541@kurims.kyoto-u.junet>
To: Common-Lisp@su-ai.arpa
Subject: some questions
Date: Fri, 30 May 1986 03:29 EDT
From: Rob MacLachlan <Shasta!RAM@λλ>
To: miller.pa@XEROX.COM
Cc: Common-lisp@SU-AI.ARPA
Subject: Some questions
In-Reply-To: Msg of 30 May 1986 00:21-EDT from miller.pa at Xerox.COM
Status: R
Date: Friday, 30 May 1986 00:21-EDT
From: miller.pa at Xerox.COM
To: Common-lisp at SU-AI.ARPA
Re: Some questions
Now that all you people and companies out there are doing all these
common-lisp compilers, I'd like to ask you some questions:
Do you transform the source to continuation passing style before
compiling?
How happy are you with this decision?
If you don't, do you do tail-recursion optimizations anyway?
If you do, do you do multiple values by calling the continuation with
multiple arguments?
......
Many of the Common Lisps floating around are based on Spice Lisp and
this compiler. Some exceptions are Symbolics, Lucid and KCL.
The current KCL compiler is a two-pass compiler which generates portable
C code. (I do not want to repeat the discussions on why C code and how it
is possible. Please refer to the KCL Report for this issue.) The main roles
of the first pass are:
1. to discriminate those lexical objects (variables, functions, blocks, and
tags) that are to be closed up in a closure from those not.
2. to collect optimization information such as type information and
reference information.
Most of the compile-time error checking is done during the first pass.
The first pass generates intermediate tree code that is similar to the
original Lisp code but is scattered with the collected information all around.
The second pass is the main pass and is responsible for the rest of the
compilation job. Tail-recursive optimization is done during the second pass.
Many other optimization hackings take place also during the second pass.
KCL is not a descendant of any other Lisp. The only reference material we
had was the draft of CLtL during the development of the first running version
of KCL (October 1983 to March 1984). (CLtL itself was not yet published at
that time.) We wrote every line of the KCL code by ourselves. (There is one
exception: we later obtained the code of RATIONALIZE from the Spice project
and used that code without changes.) Thus KCL was oriented for Common Lisp
from the very beginning. In particular, the compiler supports many Common
Lisp features: The fact that the KCL compiler is a two-pass compiler already
indicates this. (We could make it a one-pass compiler if the lexical closure
were not supported by Common Lisp.) In addition, the compiler takes care of
keyword parameters for compile-time dispatching of such functions as MEMBER
and ASSOC. It also tries to avoid creation of lexical closures in such
situations as in MAP functions, FUNCALL, and APPLY. It tries to avoid making
a list for &REST parameters in some situations, etc, etc, etc.... But it is
true that there still remains big room for improvement.
-- Taiichi
∂06-Jun-86 0331 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Re: long-char, kanji
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 6 Jun 86 03:31:10 PDT
Received: from utokyo-relay by csnet-relay.csnet id aa04180; 6 Jun 86 6:27 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA13546; Fri, 6 Jun 86 17:13:57+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA07149; Fri, 6 Jun 86 16:34:09+0900
Date: Fri, 6 Jun 86 16:34:09+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8606060734.AA07149@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida@UTOKYO-RELAY.CSNET, nuyens.pa@XEROX.COM
Subject: Re: long-char, kanji
>From ccut!Shasta!@SU-AI.ARPA:nuyens.pa%Xerox.COM@u-tokyo.junet Wed Jun 4 11:49:48 1986
>Date: 3 Jun 86 15:22 PDT
>Subject: re: long-char, kanji
>To: common-lisp@su-ai.ARPA
>
> ...
>representation:
>Strings are represented as homogeneous simple vectors of thin (8 bit) or
>fat (16 bit) characters. Ignoring storage taken to represent them, the
>difference between fat characters and thin characters is transparent to
>the user. In particular, since we allow fat characters in symbol print
>names, we use an equivalent of Ida's string-normalize function to
>guarantee unique representation for hashing.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
This is the most important decision point, I think.
I agree to do.
With Moon's idea, the relation of thin- and fat- is like a relation of fixnum
and bignum.
This means the characters in fat-char and in thin-char
are completely independent.
But, any character set may contain the characters which have same appearance
with standard-char.
Such as the space code, alphabetic characters, and terminating-macro characters.
Actually JIS 6226 has an another code for the standard-char.
I think, other foreign character set may have characters which have same visual
figure as standard-char.
With Moon's idea of ASSURE-FAT-STRING, once there is a fat-char in a string,
it can not be reduced
to thin-string, even if the modification made it to the string with the characters
which can be representable in thin-code only.
>
>kanji:
>NS includes all "JIS C 6226" graphic characters including the 6300 most
>common Japanese kanji. There are also Hiragana and Katakana character
>codes specified. (While there is substantial overlap with the Japanese
>kanji, Chinese characters are semantically separate and their character
>code assignments have not yet been published.)
>
The reason why I stick to kanji issue is not only I am a japanese, but I feel
it is the test case to cope with multi-byte characters and as a Common Lisper,
I feel a need to polish up the character data type.
>type hierarchy:
>Since we have char-bits-limit = char-font-limit = 1, STANDARD-CHAR is
>the same as STRING-CHAR. I agree with Moon that STRING should be
>(VECTOR CHARACTER) and provide specialisations (even though this is a
>change from the status quo). In our applications, we do as Fahlman
>suggests and use external data-structures to represent the sort of
>information encoded in "styles". (It is hard to standardize which
>attributes should be made part of style (some people claim "case" should
>be a style bit!)).
I like "style" idea also.
I don't want to use font.
>
>number of character codes required:
>At first glance it seems hard to imagine exceeding 16 bits. Note
>however that the 7200 characters in NS don't include Chinese, Korean,
>Farsi, Hindi, etc. How many times have you been *sure* that the FOO
>field wouldn't be required to be larger than 16 bits?
>
As far as the japanese character set concerned, 16 bits for char-code is enough.
But, as an international standard, I feel the room for more bits is needed.
>
>Greg Nuyens
>Text, Graphics and Printing,
>Xerox AI Systems
>
>
Masayuki Ida
ida%utokyo-relay.csnet@csnet-relay.arpa
∂08-Jun-86 2140 Hvatum.DLAB@MIT-MULTICS.ARPA Closure, Null Lexical Env.
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 8 Jun 86 21:39:51 PDT
Date: Mon, 9 Jun 86 00:35 EDT
From: Hvatum@MIT-MULTICS.ARPA
Subject: Closure, Null Lexical Env.
To: common-lisp@SU-AI.ARPA
Message-ID: <860609043512.124364@MIT-MULTICS.ARPA>
From: Steve Bacher at Draper Lab
Subject: Constructing a Closure over the Null Lexical Environment
Replying to a previous message from Miller.pa@Xerox.COM
> What about
>
> (EVAL '#'(lambda (x y) ...) NIL)
(eval '#'(lambda ...) nil) probably won't create a compiled definition,
because the interpreter (eval, that is) may create an interpretive
lexical closure when it sees (function ...), unlike the compiler which
will create a compiled lexical closure. In any case, the lambda
expression won't be compiled in (QUOTE (FUNCTION (LAMBDA ...)), which
makes sense when you think about it.
I don't think #.(eval ...) would necessarily work either, for the
reasons mentioned above. Thought: Does CL specify anything about
the nature of what is returned by #'(lambda ...) when it is evaluated
(as opposed to being compiled)? In particular, do the interpreter and
the compiler have to return isomorphic objects (as opposed to
merely functionally identical objects)?
Consider what DEFUN does in both contexts (I'm not talking about
those famed implementations that compile DEFUN's on the fly).
≠
∂09-Jun-86 0438 somewhere!hagiya@kurims.kurims.kyoto-u.junet long-char, kanji
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 9 Jun 86 04:38:09 PDT
Received: by su-shasta.arpa; Mon, 9 Jun 86 04:36:33 PDT
Received: by nttlab.ntt.junet (4.12/4.7JC-7) with TCP
id AA23501; Mon, 9 Jun 86 15:58:15 jst
From: hagiya@kurims.kurims.kyoto-u.junet
Received: by nttlab.ntt.junet (4.12/4.7JC-7) with TCP
id AA23374; Mon, 9 Jun 86 15:52:22 jst
Received: by kurims.kyoto-u.junet (2.0/4.7)
id AA00874; Thu, 5 Jun 86 19:17:09+0900
Date: Thu, 5 Jun 86 19:17:09+0900
Message-Id: <8606051017.AA00874@kurims.kyoto-u.junet>
To: Common-Lisp@su-ai.arpa
Subject: long-char, kanji
I think that all the discussions on extending character code
are made with the intent of defining the `international' version
of Common Lisp. The discussions, therefore, seem to keep the
pure version of Common Lisp intact and add some alien features
to it by introducing such (ugly) names as "FAT-...", "PLUMP-...",
etc.; as a result of the extension, the complex type hierarchy
of Common Lisp becomes more complex.
Complexity is sometimes unavoidable. However, I hope the simplest
solution will also be permitted, as Moon argues:
Another solution that should be permitted by the language is to have
only one representation for strings, which is fat enough to accomodate
all characters. In some environments the frequency of thin strings
might be low enough that the storage savings would not justify the extra
complexity of optimizing strings that contain only STRING-CHARs.
Common Lisp (or Lisp) is a very flexible language, and in an extreme
case, we can replace all the special forms, macros and functions of
Common Lisp with their Japanese (or Chinese or any language) counterparts
by preparing appropriate macro packages. In that case, the doc-strings
will also be written in Japanese. In such a completely Japanese
environment, it's silly to treat 8-bit characters in a special way.
I think that the discussions should be done along with how the extended
code will be used. We can consider several situations.
1. Programs written in one language (other than English) manipulate
data (characters or strings) in that language.
2. Programs written in English manipulate data in one language (other
than English).
3. Programs written in English manipulate data in more than one language
at the same time.
I myself like to program in Japanese even if the program does not
manipulate Japanese characters or strings. It's easier to device
function names in mother tongue than in a foreign language.
By the way, no one seems to stress the importance of extending symbol
names. If an extension, for example, allows simple strings to hold
only 8 bit-characters and symbol names should be simple strings, then
I completely disagree with that.
Masami Hagiya
∂09-Jun-86 0934 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA subset
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 Jun 86 09:34:39 PDT
Received: from utokyo-relay by csnet-relay.csnet id ab11788; 9 Jun 86 12:29 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA04240; Mon, 9 Jun 86 19:30:38+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA04960; Mon, 9 Jun 86 19:22:32+0900
Date: Mon, 9 Jun 86 19:22:32+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8606091022.AA04960@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida@UTOKYO-RELAY.CSNET
Subject: subset
This is in reply to mike@gold-hill-acorn
My basic understanding of subset issue is as follows;
1) "subset" is a subset of the "fullset".
a subset CommonLisp should NOT be a Commonlisp-like Lisp dialect.
2) In general, the language spec which have been discussed with many excellent
implementors/researchers has a tendency to graw, or it will be larger.
I welcome this tendency but there should not exist the field behind the standardization.
There should be two levels or so of language spec for Common Lisp.
3) Needs for a common lisp on small computers will be much larger.
The application on small computers are not only educational one.
As to Mike's discussion on scoping,
I want to have a strict conformance to the full or superset specification.
My experimental Lisp for 86/286 had also a "local lexical and complete global"
principle.
I found it is not good to push my scoping principle
As to CommonLoops or object oriented facility for subset,
I also want to add it. But it should be an option.
The members of working group in japan, are making a consensus about a subset.
They internally call their subset as "Common Lisp Core".
ida
ida%utokyo-relay.csnet@csnet-relay.arpa
∂09-Jun-86 1146 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM tail recursion optimization
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 9 Jun 86 11:46:34 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 16500; Fri 6-Jun-86 10:12:56 EDT
Date: Fri, 6 Jun 86 10:13 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: tail recursion optimization
To: RAM@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
References: <860603033423.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<RAM.12211792946.BABYL@C.CS.CMU.EDU>
Message-ID: <860606101309.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[Sorry about the delay in this reply. This mail was only just returned
due to network problems. Retrying; apologies if anyone gets duplicates.]
Date: Tue, 3 Jun 86 03:34 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: tail recursion optimization
To: ram@CMU-CS-C.ARPA
cc: kmp@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12211792946.BABYL@C.CS.CMU.EDU>
Message-ID: <860603033423.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
My point is that this isn't a beauty contest and your speech about
"what function calling means to me" is not going to carry any weight.
Did you read the passage I cited? On p59, in the named functions
description: "If a symbol appears as the first element of a function-
call form, then it refers to the definition established by the
innermost FLET or LABELS construct that textually contains the
reference or to the global definition (if any) if there is no such
containing construct".
The definition of DEFUN (p67) says (in a combination of text and
prose that (DEFUN name lambda-list {declaration | doc-string}* {form}*)
makes the global definition of NAME (ie, the thing referred to above)
be (LAMBDA lambda-list {declaration | doc-string}*
(BLOCK name {form}*))
I note in passing that were this adequate to assure closure of form
over name, then FLET and LABELS would be the same. The whole point of
LABELS is to address this {mis}feature of the spec which does not provide
for the closure of a named function over its own function cell.
Anyway, getting back to my argument, p95 says I can setf the
symbol-function of a symbol. (p90 defines that the symbol-function of
a symbol is what holds the global definition of a function.)
p438 assures me that compiling my program "should produce an equivalent
but more efficient program".
Given all this, I take the wording on p59 to say, effectively:
"Whether running interpreted or compiled, a piece of code which
was denoted at the source level by a list the car of which was
a function name not mentioned in any bounding FLET or LABELS
will have behavior equivalent to that which would be obtained
by applying the contents of the named function's symbol-value
cell to the evaluated argument."
I'm not interested in debating whether this is a productive or
efficient interpretation. I happen to personally prefer languages
which offer the meaning you describe. However, Common Lisp is not
such a language. I would support a move to change this aspect of
the language in a future spec, but I am adamant that the meaning
of a language must come (insofar as it is possible) from the wording
of its specification. In this case, the specification seems quite
clear.
If you beleve that this is not a correct interpretation, please cite
supporting passages. You suggested that the wording is ambiguous
but offered no supporting evidence. All of your arguments were based
on what's efficient, not what's specified. At language design time,
you worry about efficiency implications. Once you've put the word on
paper, however, you can only worry about the implication of the wording
or about how you're going to change things in a later version.
∂09-Jun-86 1147 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Why aren't char bits portable?
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 9 Jun 86 11:47:17 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17313; Mon 9-Jun-86 09:37:17 EDT
Date: Mon, 9 Jun 86 09:36 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Why aren't char bits portable?
To: COMMON-LISP@SU-AI.ARPA
cc: REM%IMSSS@SU-AI.ARPA
Supersedes: <860603211152.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <860609093644.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[Retrying mail returned due to network problems; apologies if anyone
got duplicate copies.]
There's nothing unportable about char bits. They just have to be
used correctly, but I think the necessary primitives are provided.
eg, MACSYMA has an editor which uses one-character commands and
extended commands. In some implementations, users have to use more
commands than in others, because in implementations which allow
char bits, MACSYMA will install commands on those characters.
Although this somewhat affects the behavior of the program between
implementations, I don't think the effect is likely to be serious
at the program level primarily because (with the exception of AI
programs that manipulate robot arms which in turn want to enter
key sequences on the terminal), programs mostly can't tell the
difference between not having those characters and having those
characters be available but just never executed. You have to be
careful not to use #\Control-..., of course. That's not portable.
But you can do, for example:
(DEFVAR *MY-COMMAND-TABLE* (MAKE-HASH-TABLE))
(DEFVAR *COMMAND-TABLE* NIL)
(DEFUN INSTALL-COMMAND-ON-KEY (FUNCTION CHAR &REST BIT-NAMES)
(DO ((CH CHAR (SET-CHAR-BIT CH (CAR B) T)) (B BIT-NAMES (CDR B)))
((NOT B)
(SETF (GETHASH CH *MY-COMMAND-TABLE*) FUNCTION))))
(DEFUN GET-COMMAND-ON-KEY (KEY) (GETHASH KEY *MY-COMMAND-TABLE*))
(DEFUN PROMPT (X)
(UNLESS (LISTEN) ;Tolerate line-at-a-time systems
(FORMAT T "~&~A: " X)))
(DEFUN READ-KEY-COMMAND () (PROMPT "Command") (READ-CHAR))
(DEFVAR *LAST-NUMBER* 0)
(DEFUN READ-NUMBER () (PROMPT "Value") (SETQ *LAST-NUMBER* (READ)))
(DEFUN CALCULATOR (&OPTIONAL (VAL 0) (*COMMAND-TABLE* *MY-COMMAND-TABLE*))
(DO ((CH (READ-KEY-COMMAND) (READ-KEY-COMMAND)))
((MEMBER CH '(#\X #\x)))
(LET ((FN (GET-COMMAND-ON-KEY CH)))
(COND (FN (PRINT (SETQ VAL (FUNCALL FN VAL))))
((CHAR= CH #\Newline) NIL) ;Tolerate line-at-a-time systems
(T
(FORMAT T "~&~@:C is not a defined command.~%" CH))))))
(INSTALL-COMMAND-ON-KEY #'(LAMBDA (X) X 0) #\0)
(INSTALL-COMMAND-ON-KEY #'(LAMBDA (X) (+ X (READ-NUMBER))) #\+)
(INSTALL-COMMAND-ON-KEY #'(LAMBDA (X) (- X (READ-NUMBER))) #\-)
(INSTALL-COMMAND-ON-KEY #'(LAMBDA (X) (* X (READ-NUMBER))) #\*)
(INSTALL-COMMAND-ON-KEY #'(LAMBDA (X) X) #\=)
(UNLESS (ZEROP CHAR-CONTROL-BIT)
(INSTALL-COMMAND-ON-KEY #'(LAMBDA (X) (+ X *LAST-NUMBER*)) #\+ :CONTROL)
(INSTALL-COMMAND-ON-KEY #'(LAMBDA (X) (- X)) #\- :CONTROL))
(CALCULATOR)
Command: =
0
Command: +
Value: 3
3
Command: *
Value: 4
12
Command: Control--
-12
Of course, in some implementations, it won't be possible to type Control--,
so the user of that interpretation will never observe any difference in behavior
other than the inaccessibility of certain commands. And there are no
functionalities in the above calculator which are on Control-anything which
are not otherwise accessible, so a portable program would not be "broken"
by their non-accessibility. In fact, the above program could use MAPHASH to
portably create self-documentation that worked correctly for the appropriate
implementation even if implementations varied.
Note that the thing which makes this reasonable (where package problems of
a similar nature are not) is that the funny bits are a property of a user
interface, not of a program interface.
I'm certainly willing to believe that lots of people won't use this feature,
but I do think it's meaningful. I'm also not 100% convinced that there are no
pitfalls to the style-of-use I'm proposing above, but I've not run across
any. If anyone has experience with using the above strategy or a similar one
and running into unforseen problems I've not mentioned, I'd be interested
to hear about them.
If people agree that the above program is neither faulty nor unportable, then
perhaps it or something like it could be included in the next manual draft
so that readers could see an example of the careful programming style you
have to stick to in order to make this stuff work. I admit it's not the sort
of strategy that leaps to mind the first time you see the available primitives.
The line-at-a-time issue that comes up implicitly in that example is much more
problemsome to me. I wish someone would suggest how we could deal more
satisfactorily with that.
By the way, I see no purpose in fonted char-bits. Bits are something that
it seems to me are associated with an input operation and fonts are something
associated with an output operation. I'm not sure what to draw from this,
but my impression is that it is nearly always the case that either the bits
are 0 or the font is 0, even in systems which use both bits and fonts. I
just can't imagine treating Bold Control-A different than Italic Control-A.
∂09-Jun-86 1736 Miller.pa@Xerox.COM Re: Closure, Null Lexical Env.
Received: from XEROX.COM by SU-AI.ARPA with TCP; 9 Jun 86 17:36:00 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 09 JUN 86 17:35:54 PDT
Date: 9 Jun 86 17:35 PDT
From: Miller.pa@Xerox.COM
Subject: Re: Closure, Null Lexical Env.
In-reply-to: Hvatum@MIT-MULTICS.ARPA's message of Mon, 9 Jun 86 00:35
EDT
To: Hvatum@MIT-MULTICS.ARPA
cc: common-lisp@SU-AI.ARPA
Message-ID: <860609-173554-1352@Xerox>
"(eval '#'(lambda (x y) ...) nil)" does seem to be the best (only?) way
to express "closure over null lexical environment" in common-lisp.
There is no reason for the compiler to not compile this. Both the
arguments to "eval" are constant, and there are no environmental
dependencies. This can be compiled for the same reason that "(+ 3 4)"
can be turned into a "7" at compile time. The constant list "(FUNCTION
(LAMBDA ...))" would not have to be preserved in the compiled code for
the same reason that the "3" doesn't.
I realize that probably no existing compiler compiles this, but it would
seem an easy change to make. As easy as adding some other language
construct to create such closures, but without making the language
definition any bloody larger. Any program which assumed this
enhancement would continue to work on current implementations (although
slowly).
MarkM
∂09-Jun-86 1854 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: tail recursion optimization
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 9 Jun 86 18:53:50 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 18213; Mon 9-Jun-86 21:53:34 EDT
Date: Mon, 9 Jun 86 21:52 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: tail recursion optimization
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8606031427.AA01279@fimass>
Message-ID: <860609215232.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 03 Jun 86 06:27:53 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
To answer earl's question: yes, a self-tail-recursive call is made
with a jump to the beginning of the function code.
I agree with Rob, this is an important optimization and 99% of the
time is it precisely what you want. I'd suggest that the Common
Lisp Standard state that within the defun of foo, there is an impliclit
(declare (inline foo))
and if the user plans on redefining foo while executing foo, it is his
burden to (declare (notinline foo)).
Inline is orthogonal to tail recursion optimization.
(defun foo (a b) (declare (inline foo)) (foo a (+ a b)))
is equivalent to
(defun foo (a b) (+a (+ a (+ a (+ a ...)))))
and not
(defun foo (a b) (loop (psetq a a b (+ a b))))
∂10-Jun-86 0439 RAM@C.CS.CMU.EDU tail recursion optimization
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Jun 86 04:39:37 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 10 Jun 86 07:39:21-EDT
Date: Tue, 10 Jun 1986 07:39 EDT
Message-ID: <RAM.12213678403.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: tail recursion optimization
Date: Monday, 9 June 1986 21:52-EDT
From: David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
To: common-lisp at SU-AI.ARPA
Re: tail recursion optimization
Inline is orthogonal to tail recursion optimization.
(defun foo (a b) (declare (inline foo)) (foo a (+ a b)))
is equivalent to
(defun foo (a b) (+a (+ a (+ a (+ a ...)))))
and not
(defun foo (a b) (loop (psetq a a b (+ a b))))
Yes, but I didn't say that the tail-recursive call should be
considered INLINE; I just said that it could be forced to be a full
function call by declaring it NOTINLINE. NOTINLINE isn't the opposite
of INLINE, since NOTINLINE affects things which were never declared
INLINE and is mandatory rather than advisory. NOTINLINE is an
important declaration in Common Lisp since it provides a way to tell
the compiler not to make any assumptions about the definition of a
function. I don't know to what extent current compilers do this, but
I think that when a function is declared NOTINLINE, is should be
called exactly as given, regardless of what the function is. This
inhibits any optimization of the call. It would be incorrect to
compile (+ (+ 3 4) 5) as 12 or even as (+ 3 4 5) if + was declared
NOTINLINE.
Making the function be lexically defined within the body of DEFUN is a
clean solution, but it does have some problems. Every implementation
would be required to make defun close over the definition at DEFUN
time. This would require every implementation to be changed, and
would put a serious strain on some. In particular, in the current
PERQ Spice Lisp implementation, the only way to do this would be to
make every function a lexical closure. It also have the problem that
this early binding of the name becomes a mandatory part of the
semantics, and thus couldn't be inhibited by a compiler switch.
Rob
∂10-Jun-86 0729 @GUIDO.THINK.COM:gls@AQUINAS.THINK.COM Re: tail recursion optimization
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 10 Jun 86 07:29:03 PDT
Received: from GUIDO.THINK.COM by Godot.Think.COM; Tue, 10 Jun 86 10:28:52 edt
Date: Tue, 10 Jun 86 10:29 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: tail recursion optimization
To: DCP@QUABBIN.SCRC.Symbolics.COM, common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860609215232.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-Id: <860610102938.3.GLS@GUIDO.THINK.COM>
Date: Mon, 9 Jun 86 21:52 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Tue, 03 Jun 86 06:27:53 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
To answer earl's question: yes, a self-tail-recursive call is made
with a jump to the beginning of the function code.
I agree with Rob, this is an important optimization and 99% of the
time is it precisely what you want. I'd suggest that the Common
Lisp Standard state that within the defun of foo, there is an impliclit
(declare (inline foo))
and if the user plans on redefining foo while executing foo, it is his
burden to (declare (notinline foo)).
Inline is orthogonal to tail recursion optimization.
(defun foo (a b) (declare (inline foo)) (foo a (+ a b)))
is equivalent to
(defun foo (a b) (+a (+ a (+ a (+ a ...)))))
and not
(defun foo (a b) (loop (psetq a a b (+ a b))))
But the latter appears to be a valid (and cleverly optimized)
implementation of the former.
--Guy
∂10-Jun-86 0751 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Re: Closure, Null Lexical Env.
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 10 Jun 86 07:51:14 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 2520; 10 Jun 86 10:49:55-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 23052; Tue 10-Jun-86 10:49:47-EDT
Date: Tue, 10 Jun 86 10:49 EST
Sender: mike@a
To: Miller.pa@Xerox.arpa
From: mike%Gold-Hill-Acorn@mit-live-oak.arpa
Subject: Re: Closure, Null Lexical Env.
Cc: common-lisp@SU-AI.ARPA
Date: 9 Jun 86 17:35 PDT
From: Miller.pa@Xerox.COM
"(eval '#'(lambda (x y) ...) nil)" does seem to be the best (only?) way
to express "closure over null lexical environment" in common-lisp.
NOT COMMON LISP. Eval does not take a second arg which is an environment.
(pg 323) furthermore, eval *always* uses the null lexical environment.
Your suggestion implies that eval should not be a function,
but rather, a special-form or macro since the following are not equivalent:
(let ((x #'(lambda (x y) ...)))
(eval x))
(eval #'(lambda (x y) ...))
which is surprising since
(let ((x '(lambda (x y) ...)))
(eval x))
(eval '(lambda (x y) ...))
are equivalent. In CL, eval is a function. In (eval <form>),
eval doesn't even get called until <form> has been evaluated in the
current environment. It is only if <form> evaluates to a list
that issues of what environment eval uses can be relevant.
i.e.,
(flet ((foobar (x) (eval x)))
....
(foobar #'(lambda (x y) ...)))
is entirely equivalent to (eval #'(lambda (x y) ...)).
If you want a lex-closure which has no lexical environment, then
free non-special vars within it should never be touched or they'd
produce errors (unbound lexical var I guess).
What do you want to use this device for? I can only think of one
scenario, which is as an "end of scope" device, a la the language
Pebble. Pebble uses big moby function objects (read lexical closures)
as a modularization tool, similar in spirit to the use of
environments in scheme, and intended to solve "package" problems via
function composition. To detect errors in this modularization, they
provide a scope-ender construct, so that you can know that your
function isn't getting anything from outer lexical scopes.
(personally, I don't like Pebble, but the concept seems to apply
here).
Is there any other reason that you could possibly want this
close-in-null-lexical-environment ???
mike beckerle
Gold Hill Computers
mike%gold-hill-acorn@mit-live-oak.arpa
∂10-Jun-86 0808 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Correction to reply to: Re: Closure, Null Lexical Env.
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 10 Jun 86 08:08:04 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 2522; 10 Jun 86 11:07:14-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 23054; Tue 10-Jun-86 11:07:17-EDT
Date: Tue, 10 Jun 86 11:07 EST
From: mike@a
To: Miller.pa@Xerox.COM
Subject: Correction to reply to: Re: Closure, Null Lexical Env.
Cc: common-lisp@SU-AI.ARPA
Date: 9 Jun 86 17:35 PDT
From: Miller.pa@Xerox.COM
Pleas excuse my answer involving misreading of:
"(eval '#'(lambda (x y) ...) nil)" does seem to be the best (only?) way
to express "closure over null lexical environment" in common-lisp.
There is no reason for the compiler to not compile this.
which I read as (eval #'(lambda...)). Most of the comments I made
are hash w.r.t. this. Sorry,... got to get new eyeglasses i guess.
There is still no lexical environment passed to eval.
My comments about use of null lexical environments are still valid I
think. I'd still like to know what useful work can be accomplished
using a closure in a null lexical environment. Likely I've missed
some of the CL mail about this due to mail/fs problems.
...mike
∂10-Jun-86 0830 franz!fimass!jkf@kim.Berkeley.EDU Re: tail recursion optimization
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 10 Jun 86 08:30:08 PDT
Received: by kim.Berkeley.EDU (5.51/1.14)
id AA15343; Tue, 10 Jun 86 08:30:13 PDT
Received: from fimass by franz (5.5/3.14)
id AA06427; Tue, 10 Jun 86 07:37:19 PDT
Received: by fimass (5.5/3.14)
id AA09293; Tue, 10 Jun 86 06:36:01 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Return-Path: <fimass!jkf>
Message-Id: <8606101436.AA09293@fimass>
To: David C. Plummer <ucbkim!QUABBIN.SCRC.Symbolics.COM!DCP>
Cc: common-lisp@su-ai.arpa
Subject: Re: tail recursion optimization
In-Reply-To: Your message of Mon, 09 Jun 86 21:52:00 EDT.
<860609215232.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 10 Jun 86 06:35:55 PST
>> From: David C. Plummer
>> Inline is orthogonal to tail recursion optimization.
>> (defun foo (a b) (declare (inline foo)) (foo a (+ a b)))
>> is equivalent to
>> (defun foo (a b) (+a (+ a (+ a (+ a ...)))))
>> and not
>> (defun foo (a b) (loop (psetq a a b (+ a b))))
I think that the wording of the manual is ambiguous enough that both
interpretations are correct. The manual only talks about the called
function being 'integrated into' the calling function. Your foo
function simply adds its arguments and then calls itself with the value
of the first argument and the sum. This is equivalent, in the
operations performed to
(defun foo (a b) (loop (psetq a a b (+ a b))))
rather than this
(defun foo (a b) (+a (+ a (+ a (+ a ...)))))
which will never end up doing even one addition.
Thus the second interpretation of 'inline foo' is, in my opinion, a
better job of integrating the definition of foo inline. The first
interpretation shows the danger of assuming that inline expansion
should be done exactly like macroexpansion.
-jkf
∂10-Jun-86 0858 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Some questions
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 10 Jun 86 08:58:18 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 18478; Tue 10-Jun-86 11:43:58 EDT
Date: Tue, 10 Jun 86 11:45 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Some questions
To: miller.pa@XEROX.ARPA, Common-lisp@SU-AI.ARPA
In-Reply-To: <860529-212115-1390@Xerox>
Message-ID: <860610114524.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 29 May 86 21:21 PDT
From: miller.pa@Xerox.COM
How happy are you with packages?
In particular, for those familiar T's reified lexical environments (aka
LOCALEs), can you think of any reason for preferring packages?
Can T's LOCALEs be added to the language in an upwards compatible way?
I'd like to point out, again, that packages get you thinks that locales
don't (if I understand locales properly -- someone correct me if I'm
wrong). Packages provide name scoping for symbols themselves, not for
values. Therefore, if symbolics are being used for virtue of their
identity rather than their value, packages provide name scoping and
locales do not. For example, suppose one subsystem uses the A:FOO
property of symbols, and another subsystem uses the B:FOO property.
∂10-Jun-86 1413 BRANDON@IBM.COM
Received: from IBM.COM by SU-AI.ARPA with TCP; 10 Jun 86 14:12:53 PDT
Date: 10 June 1986, 15:54:07 CT
From: "Brandon P. Cross" <BRANDON@IBM.COM>
To: common-lisp@SU-AI.ARPA
While making plans to attend AAAI in August I remembered that there was
plans to hold Common LISP meetings before, during or after the conference.
Any thoughts?
Brandon Cross
BRANDON@IBM.COM
∂10-Jun-86 1438 BRANDON@IBM.COM
Received: from IBM.COM by SU-AI.ARPA with TCP; 10 Jun 86 14:38:18 PDT
Date: 10 June 1986, 16:31:56 CT
From: "Brandon P. Cross" <BRANDON@IBM.COM>
To: Common-LISP@SU-AI.ARPA
Has anyone thought about the proposed meeting during AAAI?
Any thoughts?
Brandon
∂10-Jun-86 1633 Miller.pa@Xerox.COM Re: Some questions
Received: from XEROX.COM by SU-AI.ARPA with TCP; 10 Jun 86 16:29:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 86 16:24:08 PDT
Date: 10 Jun 86 16:23 PDT
From: Miller.pa@Xerox.COM
Subject: Re: Some questions
In-reply-to: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>'s
message of Tue, 10 Jun 86 11:45 EDT
To: DLW@QUABBIN.SCRC.Symbolics.COM
cc: miller.pa@Xerox.COM, Common-lisp@SU-AI.ARPA
Message-ID: <860610-162408-2271@Xerox>
Date: Tue, 10 Jun 86 11:45 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Date: 29 May 86 21:21 PDT
From: miller.pa@Xerox.COM
How happy are you with packages?
In particular, for those familiar T's reified lexical environments
(aka
LOCALEs), can you think of any reason for preferring packages?
Can T's LOCALEs be added to the language in an upwards compatible
way?
I'd like to point out, again, that packages get you thinks that locales
don't (if I understand locales properly -- someone correct me if I'm
wrong). Packages provide name scoping for symbols themselves, not for
values. Therefore, if symbolics are being used for virtue of their
identity rather than their value, packages provide name scoping and
locales do not. For example, suppose one subsystem uses the A:FOO
property of symbols, and another subsystem uses the B:FOO property.
I actually think your example emphasizes my point. Traditional (old)
lisps had a very simple mapping from print-names to symbols (one to
one), and awkward control over the mapping from symbols to values
(dynamic scoping). As we started to compose ever larger programs, it
became obvious that we needed better control and flexibility somewhere
in here. To achieve more flexibility mapping print-names to symbols, we
invented packages. To achieve flexibility and control mapping symbols
to values, we invented lexical closures, reified lexical environments
(locales), separate name spaces (function / "value" / type / property /
etc..), and object oriented programming.
Your example shows a need for scoping in property value space. You are
simulating this in a global property value space by using the "name
scoping" of packages. The reason I find this unsatisfying is that this
scoping happens at read time, and the reader is not part of the
computational model of the language. In the computational model of the
language you are still stuck with a global property space.
Is there a need for flexibility in the mapping from print-names to
symbols other than to simulate (poorly) flexibility in mapping symbols
to values? You are correct that packages buy you scoping of symbols
themeselves. My question is: what's this used for other than scoping
values?
BTW. The original T did have a single global property space, but I
believe that the new T (T3) has fixed that. Perhaps one of the T folk
would care to comment (I'm on shaky ground here)
MarkM
∂11-Jun-86 0002 nttlab!umemura@su-shasta.arpa Kanji, Foreign characters
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 11 Jun 86 00:01:54 PDT
Received: by su-shasta.arpa; Wed, 11 Jun 86 00:00:19 PDT
Received: by nttlab.ntt.junet (4.12/4.7JC-7) with TCP
id AA25440; Wed, 11 Jun 86 14:27:18 jst
Date: Wed, 11 Jun 86 14:27:18 jst
From: nttlab!umemura@su-shasta.arpa (Kyoji UMEMURA)
Message-Id: <8606110527.AA25440@nttlab.ntt.junet>
To: Shasta!Common-lisp@su-ai.arpa, Shasta!Fahlman%C.CS.CMU.EDU@su-score.arpa
Subject: Kanji, Foreign characters
>>Do you really want the name of some function to be
>>"FOO" in the Bodini font, so you have in that font or you can't access
>>that function? True there are some plain vanilla characters you hardly
>>ever want in the PNAME of an identifier/symbol, but in general you should
>>be able to do INTERN or STRING2ID or whatever on an arbitrary string of
>>whatever you consider legal characters. Any information that isn't
>>reasonable for coercing into a PNAME shouldn't be considered a normal part
>>of strings either. Use extended strings (fat strings or whatever) for
>>all that other cruft.
>The Japanese person who wants to include kanji etc. in PNAMEs of symbols
>(names of functions and variables mostly), I agree. Get rid of fonts
>and bit attributes in PNAMEs, but allow an implementation to have fat
>characters in vanilla strings and PNAMEs. -- One problem, how do you
>exchange programs between ASCII-only implementations and
>KANJI implementations?
>I don't know the answer.
It is necessary to convert a fat string to an unique SIMPLE-STRING and
the simple string can be converted to the original fat string. It is similar
case CHAR-INT & INT-CHAR. The character code may be implementation dependent
(for example EBCDIC or ASCII). However, the existence of "one to one mapping"
between two data types has a very important meaning for programmer. The
converting method between a fat string and a simple string might be
implementation dependent. However CLtL should define the function names for
the conversion.
If these functions are defined, the converted simple string can be used
in "foreigner"'s PNAME. The "foreigner's" documentation string can be stored
in converted simple one without any extra space. A part from foreign
characters, a documentation with fonts can be realized with the same
way. It will be useful for all CL users.
These functions might be identity function in some Japanese implementations,
where STANDARD-CHAR includes all KANJI character. Another implementation might
use escape character for converting a fat string. Another implementation use
special codes for saving space. Whatever conversion might be, a portable
code can be developed if the "one to one mapping" is defined clearly.
--- kyoji Umemura
∂11-Jun-86 0858 philbin-jim@YALE.ARPA Locales
Received: from YALE-BULLDOG.ARPA by SU-AI.ARPA with TCP; 11 Jun 86 08:57:59 PDT
Received: by Yale-Bulldog.YALE.ARPA; 11 Jun 86 11:34:52 EDT (Wed)
Date: 11 Jun 86 11:34:52 EDT (Wed)
From: James F Philbin <philbin-jim@YALE.ARPA>
Message-Id: <8606111534.AA03577@Yale-Bulldog.YALE.ARPA>
Subject: Locales
To: <Miller.pa@Xerox.COM>
Cc: Common-lisp@SU-AI.ARPA
BTW. The original T did have a single global property space, but I
believe that the new T (T3) has fixed that. Perhaps one of the T folk
would care to comment (I'm on shaky ground here)
In T3 symbols do not have associated property lists and thus there
is no property space. Symbols are used only as identifiers and
are pure, i.e. they cannot be side-effected. In place of properties
T provides Tables which are associations between keys (possibly symbols)
and values.
In my experience it is trivial to convert code which uses property lists
to code using tables. It is also trivial to implement GET and PUT using
tables.
∂11-Jun-86 0909 shebs%utah-orion@utah-cs.arpa Re: Some questions
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 11 Jun 86 09:09:22 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA00536; Wed, 11 Jun 86 10:10:46 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA03641; Wed, 11 Jun 86 10:10:40 MDT
Date: Wed, 11 Jun 86 10:10:40 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8606111610.AA03641@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: Some questions
Summary:
Expires:
References: <860610-162408-2271@Xerox>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <860610-162408-2271@Xerox> Miller.pa@Xerox.COM writes:
>
> Is there a need for flexibility in the mapping from print-names to
>symbols other than to simulate (poorly) flexibility in mapping symbols
>to values? You are correct that packages buy you scoping of symbols
>themeselves. My question is: what's this used for other than scoping
>values?
I personally don't see the purpose of packages as being to provide
"flexibility" in mapping symbols to values or to simulate such
flexibility. If you ignore the kinkier package operations (which
nobody agrees about the right behavior of anyway), then any program
is equivalent to one in which all the package references are
explicit references to internal symbols - as in
(lisp-setq user-x (lisp-cdr sys-*luser-features*))
Packages are a typing/reading aid, to avoid having to qualify
every symbol in the world, and to avoid the bad old days when
qualification of symbols was haphazard at best. One should note
that there is *no way* to create an interned symbol that is not
accessible from anywhere. Locales and lexical environments and
objects are for encapsulation, and therefore support and even
encourage creation of things that are only locally visible.
The "ultimate" Lisp system has a place both for locales and packages,
although it might be a bit complicated...
stan
∂11-Jun-86 1857 SCHERLIS@C.CS.CMU.EDU 1986 ACM Lisp and Fnl Pgg Conference
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Jun 86 18:55:29 PDT
Received: ID <SCHERLIS@C.CS.CMU.EDU>; Wed 11 Jun 86 21:55:29-EDT
Date: Wed 11 Jun 86 21:55:26-EDT
From: Bill.Scherlis@C.CS.CMU.EDU
Subject: 1986 ACM Lisp and Fnl Pgg Conference
To: common-lisp@SU-AI.ARPA
Message-ID: <12214096407.8.SCHERLIS@C.CS.CMU.EDU>
Advance Program
The 1986 ACM Conference on
LISP AND FUNCTIONAL PROGRAMMING
MIT, August 4-6, 1986.
Monday, August 4, 1986
Session 1. 9:00am -- 10:30am.
Session chair: William L. Scherlis (CMU)
Laws in Miranda.
Simon Thompson (University of Kent at Canterbury)
A Simple Applicative Language: mini-ML.
D. Clement (SEMA, Sophia-Antipolis), J. Despeyroux,
T. Despeyroux, G. Kahn (INRIA, Sophia-Antipolis)
Integrating Functional and Imperative Programming.
David K. Gifford, John M. Lucassen (Massachusetts
Institute of Technology)
Session 2. 10:55am -- 12:35pm.
Session chair: Daniel Weinreb (Symbolics, Inc.)
Experience with an Uncommon LISP.
Cyril N. Alberga, Chris Bosman-Clark, Martin Mikelsons,
Mary S. Van Deusen (IBM T. J. Watson Research Center),
Julian Padget (University of Bath)
Desiderata for the Standardization of LISP.
Julian Padget (University of Bath), et al.
Design of an Optimizing, Dynamically Retargetable
Compiler for Common Lisp.
Rodney A. Brooks (MIT, Lucid, Inc.), David B. Posner,
James L. McDonald, Jon L. White, Eric Benson,
Richard P. Gabriel (Lucid, Inc.)
The Implementation of PC Scheme.
David H. Bartley, John C. Jensen (Texas
Instruments Incorporated)
Session 3. 2:00pm -- 3:40pm.
Session chair: John H. Williams (IBM Research)
Code Generation Techniques for Functional Languages.
J. Fairbairn, S. C. Wray (University of Cambridge)
An Architecture for Mostly Functional Languages.
Tom Knight (Symbolics, Inc. and Massachusetts
Institute of Technology)
Mechanisms for Efficient Multiprocessor Combinator Reduction.
M. Castan, M. -H. Durand, G. Durrieu, B. Lecussan,
M. Lemaitre (ONERA-CERT)
The CURRY Chip.
John D. Ramsdell (The MITRE Corporation)
Session 4. 4:05pm -- 5:45pm.
Session chair: Mitchell Wand (Northeastern University)
Variations on Strictness Analysis.
Adrienne Bloss, Paul Hudak (Yale University)
Expansion-Passing Style: Beyond Conventional Macros.
R. Kent Dybvig, Daniel P. Friedman, Christopher T. Haynes
(Indiana University)
Hygienic Macro Expansion.
Eugene Kohlbecker, Daniel P. Friedman, Matthias Felleisen,
Bruce Duba (Indiana University)
Exact Real Arithmetic: A Case Study in Higher Order Programming.
Hans-J. Boehm, Robert Cartwright, Mark Riggle (Rice University)
Michael J. O'Donnell (University of Chicago)
Banquet.
INVITED TALK: The History of Lisp
John McCarthy (Stanford University)
Tuesday, August 5, 1986.
Session 5. 9:00am -- 10:40am.
Session chair: Rodney Brooks (MIT)
Reconfigurable, Retargetable Bignums: A Case Study in
Efficient, Portable Lisp System Building:
Jon L. White (Lucid, Inc.)
LISP on a Reduced-Instruction-Set-Processor.
Peter Steenkiste, John Hennessy (Stanford University)
Partitioning Parallel Programs for Macro-dataflow.
Vivek Sarkar, John Hennessy (Stanford University)
NORMA: A Graph Reduction Processor.
Mark Scheevel (Burroughs Corporation)
Session 6. 11:05am -- 12:20pm.
Session chair: Mark Wegman (IBM Research)
The Four-Stroke Reduction Engine.
Chris Clack, Simon L. Peyton Jones (University College London)
On the Use of LISP in Implementing Denotational Semantics.
Peter Lee, Uwe Pleban (The University of Michigan)
Semantics Directed Compiling for Functional Languages.
Hanne R. Nielson, Flemming Nielson (Aalborg University Center)
Session 7. 2:00pm -- 3:15pm.
Session chair: Gilles Kahn (INRIA)
Connection Graphs.
Alan Bawden (Massachusetts Institute of Technology)
Implementing Functional Languages in the Categorical
Abstract Machine.
Michel Mauny, Ascander Suarez (INRIA)
Connection Machine LISP: Fine-Grained Parallel
Symbolic Processing.
Guy L. Steele, Jr., W. Daniel Hillis (Thinking
Machines Corporation)
Session 8. 3:45pm -- 5:45pm.
Panel chair: L. Peter Deutsch (Xerox PARC and
CodeSmith Technology, Inc.)
PANEL: Object Oriented Programming in Lisp.
Wednesday, August 6, 1986.
Session 9. 9:00am -- 10:40am.
Session chair: David MacQueen (Bell Laboratories)
The Mystery of the Tower Revealed: A Non-Reflective
Description of the Reflective Tower.
Mitchell Wand (Northeastern University),
Daniel P. Friedman (Indiana University)
A Type-Inference Approach to Reduction Properties and
Semantics of Polymorphic Expressions.
John C. Mitchell (AT&T Bell Laboratories)
Equations, Sets, and Reduction Semantics for Functional
and Logic Programming.
Bharat Jayaraman (University of North Carolina at Chapel Hill)
Towards a Semantic Theory for Equational Programming Languages.
Satish Thatte (The University of Michigan)
Session 10. 11:05am -- 12:20pm.
Session chair: Richard P. Gabriel (Lucid, Inc)
A Protocol for Distributed Reference Counting.
Claus-Werner Lermen, Dieter Maurer (Universitat
des Saarlandes)
A Semantic Model of Reference Counting and its Abstraction.
Paul Hudak (Yale University)
Distributed Copying Garbage Collection.
Martin Rudalics (Institut fur Mathematik)
End of conference.
================================================================
CONFERENCE CHAIR: Richard P. Gabriel (Lucid, Inc)
PROGRAM CHAIRS: William L. Scherlis (CMU), John H. Williams (IBM)
LOCAL ARRANGEMENTS CHAIR: Robert Halstead (MIT)
PROGRAM COMMITTEE:
Rodney Brooks, MIT
L. Peter Deutsch, Xerox PARC and CodeSmith Technology, Inc.
Gilles Kahn, INRIA
David MacQueen, Bell Laboratories
J. Alan Robinson, Syracuse University
William L. Scherlis, CMU
David Turner, Kent University
Mitchell Wand, Northeastern University
Mark Wegman, IBM Research
Daniel Weinreb, Symbolics
John H. Williams, IBM Research
================================================================
Conference brochures are now being mailed by ACM. The early
registration deadline is July 7.
-------
∂12-Jun-86 1130 SCHERLIS@C.CS.CMU.EDU Lisp Conference, addendum
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 Jun 86 11:30:29 PDT
Received: ID <SCHERLIS@C.CS.CMU.EDU>; Thu 12 Jun 86 14:30:27-EDT
Date: Thu 12 Jun 86 14:30:25-EDT
From: Bill.Scherlis@C.CS.CMU.EDU
Subject: Lisp Conference, addendum
To: common-lisp@SU-AI.ARPA
Message-ID: <12214277536.31.SCHERLIS@C.CS.CMU.EDU>
If there is anybody on this mailing list who is not an ACM member
and who would like to receive registration information for the
Lisp and Functional Programming Conference, please send a note
to Marce Zaragoza here at CMU (Zaragoza@C.CS.CMU.EDU). Don't
forget to include your physical mailing address.
Bill Scherlis
-------
∂16-Jun-86 0658 buy%bach.DEC@decwrl.DEC.COM packages and portability
Received: from DECWRL.DEC.COM by SU-AI.ARPA with TCP; 16 Jun 86 06:58:37 PDT
Received: from DEC-RHEA.ARPA (dec-rhea) by decwrl.DEC.COM (4.22.05/4.7.34)
id AA08975; Mon, 16 Jun 86 06:58:58 pdt
Message-Id: <8606161358.AA08975@decwrl.DEC.COM>
Date: Monday, 16 Jun 1986 06:58:22-PDT
From: buy%bach.DEC@decwrl.DEC.COM
To: common-lisp@su-ai.ARPA, cl%bach.DEC@decwrl.DEC.COM,
buy%bach.DEC@decwrl.DEC.COM
Subject: packages and portability
This note relates to the discussion about packages and portability
that recently took place in this digest. The major focus of the
discussion has been the definition of a mutually agreed-upon package
configuration to suitably support the portability of Common LISP
programs across different implementations. This issue is currently
under investigation by the VAX LISP development group here at DEC and
we would like to present our viewpoint on the subject.
Although many different suggestions have been made during this
discussion, it appears that an agreement was reached on a number
of points. Here are some of the points:
1. Symbols denoting Common LISP defined objects should be contained
in a pure Common LISP package. These symbols are owned and
external in this package and no other external symbols should
appear in this package. So far, most participants in the
discussion appear to have agreed that the name of this package
should be LISP.
2. Symbols denoting implementation specific language extensions
should be contained in a separate package. Such a package may or
may not use the package containing pure Common LISP definitions.
Based on these points, we would like to propose the following outline
for the package configuration of future releases of VAX LISP:
1. Two packages are used: one to contain external symbols denoting
pure Common LISP definitions, the other to contain external
symbols denoting both pure Common LISP definitions and VAX LISP
specific definitions.
2. The default environment (i.e. the USER package) uses the extended
package (i.e. the package containing symbols both for pure Common
LISP and for VAX LISP specific definitions).
3. The default :USE arguments to MAKE-PACKAGE and IN-PACKAGE are also
the extended package.
A first observation about the naming of the above mentioned packages
is in order. Although some agreement was reached on LISP being the
name of the pure Common LISP package, we believe that a more specific
name, such as COMMON-LISP, is probably more appropriate. This is
because the name COMMON-LISP better captures the desired semantics
of this package, that is, to contain only the Common LISP subset of a
LISP implementation. We obviously recognize the benefits of adopting
a standard name for this package and are therefore open to discussion
about this issue. As far as the extension package is concerned, the
name VAX-LISP is our preferred choice for the same reason as the name
COMMON-LISP for the previous package. Notice that this proposal
contradicts the specifications in CLtL, in that no provision is made
for a package named LISP (p. 181). However, we believe that the spec
of the LISP package in CLtL is ambiguous and should be modified in
any case, because it does not indicate whether LISP should contain
just the Common LISP subset or the implementation specific extensions
as well. Moreover, this scheme leaves each site using VAX LISP the
freedom to use the name LISP as a nickname for either the pure Common
LISP or the extended package. Although we do not advocate the use of
the package name LISP in future applications because it is too
generic, it is clear that existing applications may make use of it
for reasons of compatibility with older versions.
Aside from naming considerations, this proposal has a number of
advantages in our view. First, it is relatively easy to create a pure
Common LISP, portable environment by use of:
(MAKE-PACKAGE 'xxx :USE 'COMMON-LISP), or
(IN-PACKAGE 'xxx :USE 'COMMON-LISP)
Second, it is reasonably easy to remove extended definitions from the
USER environment:
(UNUSE-PACKAGE 'VAX-LISP)
(COMMON-LISP:USE-PACKAGE 'COMMON-LISP)
Third, the default user environment (i.e. the USER package) is
consistent with the default environment provided by MAKE-PACKAGE and
IN-PACKAGE. Although this aspect may not be crucial in the future
package structure, it is likely to enhance the ease of use and
conceptual clarity of the package system, especially to new LISP
users. Notice that in this case writers of portable code need to
explicitly specify default values to MAKE-PACKAGE and IN-PACKAGE in
order to get a pure Common LISP enviroment. This is consistent with
the fact that portable code writers are likely to be required to
have a more thorough knowledge of the package system than new users
would.
Special attention needs to be given to the problem of white page
objects whose CLtL definition has been extended by an implementation.
At the least, we plan to emphasize in our documentation those aspects
of CLtL specified objects that have been extended by the VAX LISP
implementation. In addition, we are also considering providing double
implementations for objects that have undergone significant
extensions in our implementation, such as FORMAT and MAKE-ARRAY.
A last remark is about a variable (or a SETF'able function) bound to
the package to be used as the default to MAKE-PACKAGE and IN-PACKAGE.
We believe that this variable would be meaningful only if all Common
LISP implementations agree not only on its syntax and semantics, but
also on its initial value. For the time being, in our opinion, this
variable is not required in order for people to write portable Common
LISP code, although we are again willing to consider other proposals
as well. Thanks,
Ugo Buy
ARPAnet: BUY%BARTOK@HUDSON.DEC.COM
∂16-Jun-86 0937 franz!fimass!jkf@kim.Berkeley.EDU Re: packages and portability
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 16 Jun 86 09:37:10 PDT
Received: by kim.Berkeley.EDU (5.51/1.14)
id AA10921; Mon, 16 Jun 86 09:37:30 PDT
Received: from fimass by franz (5.5/3.14)
id AA04774; Mon, 16 Jun 86 09:29:32 PDT
Received: by fimass (5.5/3.14)
id AA12569; Mon, 16 Jun 86 08:27:29 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Return-Path: <fimass!jkf>
Message-Id: <8606161627.AA12569@fimass>
To: ucbkim!decwrl.DEC.COM!buy%bach.DEC
Cc: common-lisp@su-ai.arpa
Subject: Re: packages and portability
In-Reply-To: Your message of Mon, 16 Jun 86 06:58:22 PDT.
<8606161358.AA08975@decwrl.DEC.COM>
Date: Mon, 16 Jun 86 08:27:24 PST
Our package setup is a bit different than the DEC proposal described
by Ugo Buy.
1. The 'lisp' package contains only those external symbols defined by
the book. [DEC would call this the common-lisp package. I could
see this name change being useful for people with existing lisps
who want to embed a common lisp into their lisp. If these people
come forth and lobby for it, I suppose I'll agree, otherwise I think
it should continue to be named lisp.]
2. The 'excl' package contains external symbols which are distinct from
those of the 'lisp' package, and these symbols represent most of
our extensions. We thus agree with DEC that each implementation should
define an extension package with a unique name. We don't think that
the lisp package symbols should be imported into this package
(more on this below).
3. If extensions must be made to the functions in the book, (i.e. symbols
in the lisp package) they are made only where upward compatibility
is preserved, and it is clearly documented in the manual that these
are non-portable extensions. [What I'm talking about are
things like extra keywords to 'compile-file'. The list of such extensions
will always be less than a page].
4. The 'user' package uses both the 'lisp' and 'excl' packages in the
version of common lisp we ship. It is a simple matter to unuse
the 'excl' package in your init file (or globally for all users)
if you want a pure common lisp. [as long as you don't use the
lisp package function extensions documented it the book]
5. The default use list for the make-package and in-package functions
is still the 'lisp' package. This is important, it makes the user
identify non-portable code. It prevents the user from running
ExCL only code in Vax-Lisp (as soon as the in-package is executed,
Vax-Lisp will complain about a missing excl package).
In point (2) I mentioned that the excl package doesn't contain the lisp
package symbols. This permits you to go into extended mode with a
use-package and out of extended mode with unuse-package (in the DEC mode,
the package switch is more complex). But more important, I think that
our way is 'extensible' to the future when extensions come in their own
package. In fact right now we have our standard extensions in the 'excl'
package, but we also have a 'foreign-functions' package, two graphics packages,
a flavors package, a 'cross-reference' package, etc. In our model, you
can simply use the packages you want to work in. The excl package extensions
aren't treated any differently than the other extensions and I don't see
why they should be.
-john foderaro
franz inc.
∂16-Jun-86 1016 Hvatum.DLAB@MIT-MULTICS.ARPA ' (lambda...)
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 16 Jun 86 10:16:07 PDT
Date: Mon, 16 Jun 86 13:15 EDT
From: Hvatum@MIT-MULTICS.ARPA
Subject: ' (lambda...)
To: common-lisp@SU-AI.ARPA
Message-ID: <860616171540.788413@MIT-MULTICS.ARPA>
From: Steve Bacher (C.S.Draper Lab)
Subject: Evaluating '#'(lambda ...)
To: Miller.pa at XEROX.COM
cc: common-lisp at SU-AI
OK, let's say that you have an optimizing compiler that can take
function calls containing only constants and reduce them at compile
time. This is effectively done by performing the operation at
compiler time and inserting the result into the compiled code,
n'est-ce pas? Now, first of all the compiler needs a list of function
names for which it can perform this optimization (obviously CONS and
other side-effecting functions are not candidates). Let us say that
EVAL is in this list. Now, the way the compiler would handle a form
(EVAL 'FOO NIL) - assuming a slightly-uncommon-lisp EVAL that takes
a second argument for which NIL represents the null lexical
environment - is for the compiler to invoke EVAL on the constant FOO
in the lexical environment specified by NIL, and plug that value into
the code where the call to EVAL originally appeared.
Now, let's take the case of
(eval '#'(lambda (x y) ...) nil)
The compiler will strip the quote mark off '#'(lambda (x y) ...)
and end up with (FUNCTION (LAMBDA (X Y) ...)), true? Now, the compiler
then passes this form (a LIST whose CAR is the atom FUNCTION) to EVAL
and comes up with some object.
***********************************************************************
The nature of this object is what I was hoping to get some answers
to, since this seems unclear. It has been flamed at great length
what #'FOO means where FOO is a symbol, but not what #'(LAMBDA (X Y)
(FOO X Y)) means.
***********************************************************************
Anyhow, as you may be able to see at this point, the implementation must
ALREADY have the capability (as implemented within EVAL itself) of
creating the correct kind of object to insert in the code at this point.
If it does, then there must be some way of creating it (which the
programmer ought to be able to get hands on). Thus, we are back to the
original question. If it does not, then there is no solution to the
problem in the given implementation, and the creation of
null-lexical-environment closures is not possible.
If EVAL of #'(lambda ...) does not return the same kind of object as
compiling #'(lambda ...), which I suspect it doesn't (or what would
be the difference between compilation and interpretation?), then
this would produce an unsatisfactory (to my mind) result - one might
as well code '(lambda ...).
But a further point is that it may not even be desirable to optimize
calls to EVAL. After all, such an optimization would bypass a user
setting of *EVALHOOK*, for example.
- SEB (at CSDL)
≠
∂16-Jun-86 1135 buy%bach.decnet@hudson.dec.com packages and portability
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 16 Jun 86 11:35:14 PDT
Date: 16 Jun 86 09:46:00 EST
From: "BACH::BUY" <buy%bach.decnet@hudson.dec.com>
Subject: packages and portability
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: buy
Reply-To: "BACH::BUY" <buy%bach.decnet@hudson.dec.com>
This note relates to the discussion about packages and portability
that recently took place in this digest. The major focus of the
discussion has been the definition of a mutually agreed-upon package
configuration to suitably support the portability of Common LISP
programs across different implementations. This issue is currently
under investigation by the VAX LISP development group here at DEC and
we would like to present our viewpoint on the subject.
Although many different suggestions have been made during this
discussion, it appears that an agreement was reached on a number
of points. Here are some of the points:
1. Symbols denoting Common LISP defined objects should be contained
in a pure Common LISP package. These symbols are owned and
external in this package and no other external symbols should
appear in this package. So far, most participants in the
discussion appear to have agreed that the name of this package
should be LISP.
2. Symbols denoting implementation specific language extensions
should be contained in a separate package. Such a package may or
may not use the package containing pure Common LISP definitions.
Based on these points, we would like to propose the following outline
for the package configuration of future releases of VAX LISP:
1. Two packages are used: one to contain external symbols denoting
pure Common LISP definitions, the other to contain external
symbols denoting both pure Common LISP definitions and VAX LISP
specific definitions.
2. The default environment (i.e. the USER package) uses the extended
package (i.e. the package containing symbols both for pure Common
LISP and for VAX LISP specific definitions).
3. The default :USE arguments to MAKE-PACKAGE and IN-PACKAGE are also
the extended package.
A first observation about the naming of the above mentioned packages
is in order. Although some agreement was reached on LISP being the
name of the pure Common LISP package, we believe that a more specific
name, such as COMMON-LISP, is probably more appropriate. This is
because the name COMMON-LISP better captures the desired semantics
of this package, that is, to contain only the Common LISP subset of a
LISP implementation. We obviously recognize the benefits of adopting
a standard name for this package and are therefore open to discussion
about this issue. As far as the extension package is concerned, the
name VAX-LISP is our preferred choice for the same reason as the name
COMMON-LISP for the previous package. Notice that this proposal
contradicts the specifications in CLtL, in that no provision is made
for a package named LISP (p. 181). However, we believe that the spec
of the LISP package in CLtL is ambiguous and should be modified in
any case, because it does not indicate whether LISP should contain
just the Common LISP subset or the implementation specific extensions
as well. Moreover, this scheme leaves each site using VAX LISP the
freedom to use the name LISP as a nickname for either the pure Common
LISP or the extended package. Although we do not advocate the use of
the package name LISP in future applications because it is too
generic, it is clear that existing applications may make use of it
for reasons of compatibility with older versions.
Aside from naming considerations, this proposal has a number of
advantages in our view. First, it is relatively easy to create a pure
Common LISP, portable environment by use of:
(MAKE-PACKAGE 'xxx :USE 'COMMON-LISP), or
(IN-PACKAGE 'xxx :USE 'COMMON-LISP)
Second, it is reasonably easy to remove extended definitions from the
USER environment:
(UNUSE-PACKAGE 'VAX-LISP)
(COMMON-LISP:USE-PACKAGE 'COMMON-LISP)
Third, the default user environment (i.e. the USER package) is
consistent with the default environment provided by MAKE-PACKAGE and
IN-PACKAGE. Although this aspect may not be crucial in the future
package structure, it is likely to enhance the ease of use and
conceptual clarity of the package system, especially to new LISP
users. Notice that in this case writers of portable code need to
explicitly specify default values to MAKE-PACKAGE and IN-PACKAGE in
order to get a pure Common LISP enviroment. This is consistent with
the fact that portable code writers are likely to be required to
have a more thorough knowledge of the package system than new users
would.
Special attention needs to be given to the problem of white page
objects whose CLtL definition has been extended by an implementation.
At the least, we plan to emphasize in our documentation those aspects
of CLtL specified objects that have been extended by the VAX LISP
implementation. In addition, we are also considering providing double
implementations for objects that have undergone significant
extensions in our implementation, such as FORMAT and MAKE-ARRAY.
A last remark is about a variable (or a SETF'able function) bound to
the package to be used as the default to MAKE-PACKAGE and IN-PACKAGE.
We believe that this variable would be meaningful only if all Common
LISP implementations agree not only on its syntax and semantics, but
also on its initial value. For the time being, in our opinion, this
variable is not required in order for people to write portable Common
LISP code, although we are again willing to consider other proposals
as well. Thanks,
Ugo Buy
ARPAnet: BUY%BARTOK@HUDSON.DEC.COM
------
∂16-Jun-86 1402 pyramid!bein@SUN.COM compiled-function-p
Received: from SUN.COM by SU-AI.ARPA with TCP; 16 Jun 86 14:02:21 PDT
Received: from sun.uucp by sun.com (3.2/SMI-3.0)
id AA13232; Mon, 16 Jun 86 13:56:27 PDT
Received: by sun.uucp (1.1/SMI-3.0)
id AA18443; Mon, 16 Jun 86 14:02:20 PDT
Received: by pyramid (4.12/3.14)
id AA21964; Mon, 16 Jun 86 13:54:01 pdt
Date: 16 Jun 1986 13:46-PDT
From: David Bein <pyramid!bein@SUN.COM>
Subject: compiled-function-p
To: common-lisp@su-ai.ARPA
Message-Id: <519338806/bein@pyramid>
Is compiled-function-p supposed to answer true for FEXPRs?
What should compiled-function-p do when it comes across some
evil looking thing which represents a compiled-closure and which
is truly funcall'able like a regular compiled lambda body?
--David
p.s. Please excuse me if this question has been posted before
as I am sure it must have been.
∂16-Jun-86 1728 buy%bach.decnet@hudson.dec.com packages and portability
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 16 Jun 86 17:27:40 PDT
Date: 16 Jun 86 19:58:00 EST
From: "BACH::BUY" <buy%bach.decnet@hudson.dec.com>
Subject: packages and portability
To: "common-lisp" <common-lisp@su-ai.arpa>
Reply-To: "BACH::BUY" <buy%bach.decnet@hudson.dec.com>
It seems that my previous message was mistankenly sent three times to
the mailing list and I would like to apologize for any confusion that
that may have caused. I will make sure only one copy of this message
is mailed out.
This is in reply to John Foderaro's message about the package
configuration adopted by Franz for their implementation of Common
LISP. A number of points were brought up evidencing differences
between the DEC proposed configuration and the Franz configuration.
> 2. The 'excl' package contains external symbols which are distinct from
> those of the 'lisp' package, and these symbols represent most of
> our extensions. We thus agree with DEC that each implementation
> should define an extension package with a unique name. We don't
> think that the lisp package symbols should be imported into this
> package (more on this below).
>...
>
> 4. The 'user' package uses both the 'lisp' and 'excl' packages in the
> version of common lisp we ship. It is a simple matter to unuse
> the 'excl' package in your init file (or globally for all users)
> if you want a pure common lisp. [as long as you don't use the
> lisp package function extensions documented it the book]
> ...
>
> In point (2) I mentioned that the excl package doesn't contain the
> lisp package symbols. This permits you to go into extended mode with
> a use-package and out of extended mode with unuse-package (in the DEC
> mode, the package switch is more complex). But more important, I
> think that our way is 'extensible' to the future when extensions come
> in their own package. In fact right now we have our standard
> extensions in the 'excl' package, but we also have a
> 'foreign-functions' package, two graphics packages, a flavors
> package, a 'cross-reference' package, etc. In our model, you can
> simply use the packages you want to work in. The excl package
> extensions aren't treated any differently than the other extensions
> and I don't see why they should be.
I agree about the fact that the uniformity of your package model is
indeed appealing, however this model may prove inconvenient to use in
the case of symbols that have two distinct definitions, one each in
the pure Common LISP and in the extended package. In fact, I think
that a desirable feature of the future package configuration is not
to preclude the possibility for a symbol to be defined in both the
pure Common LISP and the extended package. According to your model,
in the case of symbols defined in both packages, the creation of an
extended environment (similar to the USER package) always results
into name conflicts, unless shadowing is used, which may be tedious
to do.
Furthermore, the resolution of a name conflict between two external
symbols inherited by the using package may cause one of the two
symbols to be imported (CLtL p. 180), which will render such a symbol
insensitive to subsequent UNUSE-PACKAGE operations (CLtL p.177). So,
should name conflicts caused by (USE-PACKAGE 'excl) be resolved in
favor of the extended symbols, subsequent (UNUSE-PACKAGE 'excl) will
not get rid of the extended definitions for such symbols. The model
we proposed can deal uniformly and (relatively conveniently) with
symbols defined in one or both of the two packages. To switch from an
entended to a pure Common LISP environment:
(UNUSE-PACKAGE 'VAX-LISP)
(COMMON-LISP:USE-PACKAGE 'COMMON-LISP)
Viceversa, to switch from a Common LISP to an extended environment:
(UNUSE-PACKAGE 'COMMON-LISP)
(COMMON-LISP:USE-PACKAGE 'VAXLISP)
In addition, it is not immediately obvious to me that the package
name EXCL is going to be exclusively used by Franz: it sounds like an
acronym for extended Common LISP and may therefore be used by
multiple implementations.
> 3. If extensions must be made to the functions in the book, (i.e.
> symbols in the lisp package) they are made only where upward
> compatibility is preserved, and it is clearly documented in the
> manual that these are non-portable extensions. [What I'm talking
> about are things like extra keywords to 'compile-file'. The list
> of such extensions will always be less than a page].
I agree that extensions to white page objects should be upward
compatible, however I don't think it is possible to establish a fixed
upper bound on such extensions and on the amount of documentation
for each of the extensions (e.g. the VAX LISP User Guide
documentation for COMPILE-FILE is three pages long). Also, site
specific extensions to white page objects should be stated to be
non-portable in the on-line documentation as well. In summary, I
think that the most reliable way to deal with white page extended
objects is to provide two distinct definitions, one for each of the
two packages. Although double definitions may not appear to be
necessary for the time being and may be tedious to implement, I think
that they should not be precluded a priori from future
implementations.
Ugo Buy
ARPAnet: BUY%BARTOK.DEC@DECWRL.ARPA
------
∂16-Jun-86 1958 FAHLMAN@C.CS.CMU.EDU compiled-function-p
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Jun 86 19:58:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 16 Jun 86 22:52:47-EDT
Date: Mon, 16 Jun 1986 22:52 EDT
Message-ID: <FAHLMAN.12215417553.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: David Bein <pyramid!bein@SUN.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: compiled-function-p
In-reply-to: Msg of 16 Jun 1986 16:46-EDT from David Bein <pyramid!bein at SUN.COM>
Is compiled-function-p supposed to answer true for FEXPRs?
What should compiled-function-p do when it comes across some
evil looking thing which represents a compiled-closure and which
is truly funcall'able like a regular compiled lambda body?
There's no such thing as a FEXPR in Common Lisp, though some
implementations may use such a thing internally in implementing special
forms. I'll assume that you mean "special form" or "special operator"
or whatever we are calling it. I think that Compiled-Function-P and
Function-P should answer NIL for special forms.
Compiled-Function-P should answer T for compiled closures that are
callable like functions.
This whole business of what is a function needs work. It will be on the
agenda of things to be discussed and clarified.
-- Scott
∂16-Jun-86 2034 franz!fimass!jkf@kim.Berkeley.EDU Re: packages and portability
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 16 Jun 86 20:34:07 PDT
Received: by kim.Berkeley.EDU (5.51/1.14)
id AA03623; Mon, 16 Jun 86 20:34:29 PDT
Received: from fimass by franz (5.5/3.14)
id AA07481; Mon, 16 Jun 86 20:29:56 PDT
Received: by fimass (5.5/3.14)
id AA14485; Mon, 16 Jun 86 19:27:55 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Return-Path: <fimass!jkf>
Message-Id: <8606170327.AA14485@fimass>
To: <ucbkim!hudson.dec.com!buy%bach.decnet>
Cc: common-lisp@su-ai.arpa
Subject: Re: packages and portability
In-Reply-To: Your message of 16 Jun 86 19:58:00 EST.
<8606170042.AA01941@kim.Berkeley.EDU>
Date: Mon, 16 Jun 86 19:27:49 PST
>> I agree about the fact that the uniformity of your package model is
>> indeed appealing, however this model may prove inconvenient to use in
>> the case of symbols that have two distinct definitions, one each in
>> the pure Common LISP and in the extended package. In fact, I think
>> that a desirable feature of the future package configuration is not
>> to preclude the possibility for a symbol to be defined in both the
>> pure Common LISP and the extended package.
I don't like to preclude anything either since I can't predict the future
nor do I know the requirements of other implementations, but I know that
right now what I've described is the better setup for our implementation.
We don't have (and never plan to have) any external symbols in common
between the lisp package and the excl package (nor any of the other
extension packages), thus users can use and unuse packages with any problems.
>> In addition, it is not immediately obvious to me that the package
>> name EXCL is going to be exclusively used by Franz: it sounds like an
>> acronym for extended Common LISP and may therefore be used by
>> multiple implementations.
By the same token, 'vax-lisp' is a pretty generic package name, and I might
want to use it to store my vax-only lisp functions. I think that with
a little cooperation we can manage to avoid stepping on eachother's package
names.
>> I agree that extensions to white page objects should be upward
>> compatible, however I don't think it is possible to establish a fixed
>> upper bound on such extensions and on the amount of documentation
>> for each of the extensions (e.g. the VAX LISP User Guide
>> documentation for COMPILE-FILE is three pages long).
I didn't mean to limit the length of the documentation of the extended
functions, just that it is our goal that the actual list of changes will
fit on one page. An example of a change is
compile-file: takes an extra keyword argument :cross-reference
The documentation that describes compile-file is elsewhere. The
user interested in portabily can search his code to see if the
:cross-reference keyword is passed to compile-file.
>> In summary, I
>> think that the most reliable way to deal with white page extended
>> objects is to provide two distinct definitions, one for each of the
>> two packages. Although double definitions may not appear to be
>> necessary for the time being and may be tedious to implement, I think
>> that they should not be precluded a priori from future
>> implementations.
We agree that double definitions aren't needed now and would be tedious
to implement. I personally feel that they are also too dangerous. If it was
determined that adding something like the :cross-reference argument to
compile-file was an illegal extension, then I would rather create a new
function (excl:excl-compile-file) than create a double definition for
compile-file.
What extensions do you see in the future that would make double
definitions necessary?
-john foderaro
franz inc.
∂17-Jun-86 0618 BRANDON@IBM.COM Common LISP meeting at AAAI
Received: from IBM.COM by SU-AI.ARPA with TCP; 17 Jun 86 06:18:44 PDT
Date: 17 June 1986, 08:14:49 CT
From: "Brandon P. Cross" <BRANDON@IBM.COM>
To: common-lisp@SU-AI.ARPA
Message-Id: <061786.081454.brandon@ibm.com>
Subject: Common LISP meeting at AAAI
Has anyone thought about when any Common LISP meetings will take place
during AAAI?
Brandon Cross
∂17-Jun-86 0803 FAHLMAN@C.CS.CMU.EDU Common LISP meeting at AAAI
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Jun 86 08:02:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 17 Jun 86 10:59:55-EDT
Date: Tue, 17 Jun 1986 10:59 EDT
Message-ID: <FAHLMAN.12215549899.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Brandon P. Cross" <BRANDON@IBM.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: Common LISP meeting at AAAI
In-reply-to: Msg of 17 Jun 1986 08:14:49 CT from Brandon P. Cross <BRANDON at IBM.COM>
We're trying (rather hurriedly and belatedly) to get our act together on
activities at the Lisp Conference. It turns out that there's little
free time during the cofnerence and a lot of people have rather tight
travel plans before and after. As of now, it looks like there will not
be a mass meeting on Common Lisp of the sort we had last January. There
probably will be a meeting on object-oriented facilities for Common Lisp
on the afternoon of Wednesday, Aug 6, after the conference is officially
over. Dick Gabriel is working on setting this up. The steering and
technical committees will be meeting during the conference and we expect
to have some joint meetings with the people working on standardization
in Europe and Japan.
I believe that the first official meeting of the X3J13 subcommittee will
be in Washington on Sept 23 and 24. There will be a handout at the Lisp
conference describing how people can participate in this activity.
(People plugged into this mailing list will see this information
electronically.)
-- Scott
∂17-Jun-86 0853 VERACSD@USC-ISI.ARPA Re: packages and portability
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 17 Jun 86 08:53:24 PDT
Date: 17 Jun 1986 11:31-EDT
Sender: VERACSD@USC-ISI.ARPA
Subject: Re: packages and portability
From: VERACSD@USC-ISI.ARPA
To: buy%bach.decnet@HUDSON.DEC.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]17-Jun-86 11:31:19.VERACSD>
In-Reply-To: The message of 16 Jun 86 19:58:00 EST from "BACH::BUY" <buy%bach.decnet@hudson.dec.com>
What is a "white page object" ?
Thanks in advance.
-- Cris Kobryn
∂17-Jun-86 1001 snyder%hplsny@hplabs.HP.COM Re: packages and portability
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 17 Jun 86 10:00:16 PDT
Received: from hplsny by hplabs.HP.COM ; Tue, 17 Jun 86 09:59:15 pdt
Received: by hplsny ; Tue, 17 Jun 86 09:58:58 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8606171658.AA00290@hplsny>
Date: Tuesday, June 17, 1986 09:58:20
Subject: Re: packages and portability
To: franz!fimass!jkf@kim.Berkeley.EDU
Cc: common-lisp@su-ai
In-Reply-To: Your message of 16-Jun-86 19:27:49
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
We agree that double definitions aren't needed now and would be tedious to
implement. I personally feel that they are also too dangerous. If it was
determined that adding something like the :cross-reference argument to
compile-file was an illegal extension, then I would rather create a new
function (excl:excl-compile-file) than create a double definition for
compile-file.
Hmmm. I always thought that one of the virtues of having a package system is
that you don't have to resort to sticking prefixes on your function names.
Defining distinct symbols LISP:COMPILE-FILE and EXCL:COMPILE-FILE seems
cleaner to me, if the intent is that EXCL:COMPILE-FILE is a localized version
of LISP:COMPILE-FILE. I think we should support this sort of thing.
-------
∂17-Jun-86 1336 DSinger@SRI-KL.ARPA The Reader and lower-case characters
Received: from SRI-KL.ARPA by SU-AI.ARPA with TCP; 17 Jun 86 13:36:36 PDT
Date: Tue 17 Jun 86 13:02:43-PDT
From: David Singer <DSinger@SRI-KL>
Subject: The Reader and lower-case characters
To: common-lisp%SU-AI@SRI-KL
cc: DSinger@SRI-KL
Forgive me if I have missed something, or if this has been aired before ...
How does one persuade the reader not to uppercase lowercase characters in
symbols. The reader description, page 337 steps 7 and 8, does not make
the uppercasing optional, and there doesn't seem to be an easy way to
change that. (I'm translating a lisp-like language which differentiates
case). Do I really have to build my own reader, or have I missed an easy
way out?
Thanks
Dave Singer
-------
∂17-Jun-86 1916 FAHLMAN@C.CS.CMU.EDU Out-of-range subsequences
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Jun 86 19:15:29 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 17 Jun 86 22:15:12-EDT
Date: Tue, 17 Jun 1986 22:15 EDT
Message-ID: <FAHLMAN.12215672858.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Daniels.pa@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Subject: Out-of-range subsequences
In-reply-to: Msg of 17 Jun 1986 17:43-EDT from Daniels.pa at Xerox.COM
Is it an error for a subsequence description to index elements that are
"off the end" of a sequence? By analogy with ELT, it should be, but I
have seen a couple of implementations that quietly take the intersection
of the intervals and go on from there? This would be true for SUBSEQ as
well as any sequence function that allows :START and :END keywords.
In particular, is (subseq #(1 2 3) 0 5) an error?
I don't see any clear statement in the book about this, but in my
opinion this should "be an error" and should probably be required to
signal an error.
-- Scott
∂17-Jun-86 1736 Daniels.pa@Xerox.COM Out-of-range subsequences
Received: from XEROX.COM by SU-AI.ARPA with TCP; 17 Jun 86 17:36:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 JUN 86 16:36:23 PDT
Date: 17 Jun 86 14:43 PDT
From: Daniels.pa@Xerox.COM
Subject: Out-of-range subsequences
To: common-lisp@su-ai.arpa
cc: Daniels.pa@Xerox.COM
Message-ID: <860617-163623-1048@Xerox>
Is it an error for a subsequence description to index elements that are
"off the end" of a sequence? By analogy with ELT, it should be, but I
have seen a couple of implementations that quietly take the intersection
of the intervals and go on from there? This would be true for SUBSEQ as
well as any sequence function that allows :START and :END keywords.
In particular, is (subseq #(1 2 3) 0 5) an error?
-- Andy. --
∂17-Jun-86 1709 FAHLMAN@C.CS.CMU.EDU The Reader and lower-case characters
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Jun 86 17:08:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 17 Jun 86 20:07:48-EDT
Date: Tue, 17 Jun 1986 20:07 EDT
Message-ID: <FAHLMAN.12215649666.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: David Singer <DSinger@SRI-KL.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: The Reader and lower-case characters
In-reply-to: Msg of 17 Jun 1986 16:02-EDT from David Singer <DSinger at SRI-KL>
There is no way specified in Common Lisp to tell the reader not to
transform symbols to upper case, though some implementations provide
this facility. For an individual symbol, you could put vertical bars
around it or call INTERN yourself with the mixed-case string.
-- Scott
∂17-Jun-86 2036 franz!fimass!jkf@kim.Berkeley.EDU Re: packages and portability
Received: from [128.32.130.7] by SU-AI.ARPA with TCP; 17 Jun 86 20:33:52 PDT
Received: by kim.Berkeley.EDU (5.51/1.14)
id AA22650; Tue, 17 Jun 86 20:34:13 PDT
Received: from fimass by franz (5.5/3.14)
id AA02069; Tue, 17 Jun 86 20:23:11 PDT
Received: by fimass (5.5/3.14)
id AA16275; Tue, 17 Jun 86 19:21:09 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Return-Path: <fimass!jkf>
Message-Id: <8606180321.AA16275@fimass>
To: Alan Snyder <ucbkim!hplabs.HP.COM!snyder%hplsny>
Cc: common-lisp@su-ai.arpa
Subject: Re: packages and portability
In-Reply-To: Your message of Tue, 17 Jun 86 09:58:20 GMT.
<8606171658.AA00290@hplsny>
Date: Tue, 17 Jun 86 19:21:03 PST
>> Hmmm. I always thought that one of the virtues of having a package system is
>> that you don't have to resort to sticking prefixes on your function names.
>> Defining distinct symbols LISP:COMPILE-FILE and EXCL:COMPILE-FILE seems
>> cleaner to me, if the intent is that EXCL:COMPILE-FILE is a
>> localized version
>> of LISP:COMPILE-FILE. I think we should support this sort of thing.
>> -------
In this particular case, I think that it should be legal for me to add the
:cross-reference argument to the compile-file function in the lisp package.
Do you agree? Thus I would never have to create the function
excl-compile-file.
However if I decide that I'd like compile-file to have the form
(compile-file filename &rest functions)
and to compile only those functions listed in the named file, then
I've made a significant change to compile-file and I should give it
a new name (like excl:excl-compile-file). Using excl:compile-file would
just be confusing.
This example is pretty trivial, let's step back and look at the big
picture. The DEC proposal and our proposal are trying to solve the same
problem: creation of a lisp system in which is possible to write portable
programs as well as implementation specific (non-portable) program.
The DEC proposal does this by creating a package of functions which
follow the spec set out in CLtL, and do nothing more. Functions which
have extended behavior have the same name and are found in another
package. Nothing is said about how different the extended functions
can be from the original ones.
The ExCL proposal is to have a single function to implement
each of the CLtL functions and their extensions, and the only extensions
that are permitted are those that are upward compatible (and typically
involve adding a keyword argument). Furthermore the number of such extensions
will be small and well documented.
Under both proposals it is easy to write portable code. To verify that your
code is portable you really have to check your source to see if you've
used any extensions. Under the DEC proposal the system will catch
non-portabilities in the CLtL functions as the code is running, but
of course it won't catch them all unless you exercise every path of the code.
In the ExCL proposal you have to take the handy 'extensions sheet' and check
by hand that you haven't used any extensions. Of course, the careful
programmer will simply not use extensions in portable code.
Under the ExCL proposal it is simple and natural to switch between the
extended and portable modes. Under the DEC proposal the procedure is
more difficult.
The ExCL proposal shows off the power of the package system in the ability
to easily move into and out of the extended environment. The DEC
proposal shows off one of the big misfeatures of the package system: that you
have to go to so much trouble if you merely want to shadow one symbol
in the lisp package. Do we want users to emulate this kind of package
construction?
If we ever want to do double definitions in the future, then the DEC proposal
sets up the framework. The ExCL proposal doesn't prevent double
definitions but it doesn't set it up either. If double definitions will
be important in the future in order to implement extensions
then we should be able to come up with a few examples where they would
be important. I can't think of any. As I see it, either the extension
is so trivial you can add it to the standard definition, or the extension
is so large that you'd be better off renaming the extended function to avoid
confusion.
Sorry for being so longwinded, I think that this is one of the more
important issues to be resolved.
-john foderaro
franz inc.
∂18-Jun-86 0523 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Out-of-range subsequences
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jun 86 05:23:47 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24177; Wed 18-Jun-86 08:22:54 EDT
Date: Wed, 18 Jun 86 08:24 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Out-of-range subsequences
To: Daniels.pa@Xerox.COM, common-lisp@SU-AI.ARPA
In-Reply-To: <860617-163623-1048@Xerox>
Message-ID: <860618082448.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 17 Jun 86 14:43 PDT
From: Daniels.pa@Xerox.COM
In particular, is (subseq #(1 2 3) 0 5) an error?
What an excellent example of the sort of thing that the manual really
needs to be more explicit about.
Our implementation signals an error. It certainly seems to me
that it ought to.
∂18-Jun-86 0716 preece%ccvaxa@gswd-vms.ARPA Re: Out-of-range subsequences
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 07:15:43 PDT
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/)
id AA11649; Wed, 18 Jun 86 09:14:40 CDT
Message-Id: <8606181414.AA11649@gswd-vms.ARPA>
Date: Wed, 18 Jun 86 09:14:35 cdt
From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: Out-of-range subsequences
>
> From: Daniels.pa@Xerox.COM
>
> In particular, is (subseq #(1 2 3) 0 5) an error?
----------
Well, I agree that it ought to be clarified, so that we all to
the same thing. I'm less sure that I agree it should signal
an error, since the user could reasonably want to take
a subsequence beginning at a certain point and running up
to a certain length or the end of the strnig, whichever
comes first. If subseq is allowed to stop at end-of-string
you can do that (although the endpoint dangling out in space
is an unpretty way of specifying what you mean as a length).
If you clarify it to require and in bounds endpoint, you need
to do two operations. No big deal, but I don't think many
users would find it confusing that the operation stops at
end of string if the endpoint is out of bounds.
I'd prefer the clarification to say that the subsequence
extends to the end of the sequence or to the specified endpoint,
whichever is less, but it's not a big deal if the universal
preference is for pickiness over (marginal) convenience.
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
∂18-Jun-86 0831 buy%bizet.decnet@hudson.dec.com packages and portability
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 18 Jun 86 08:31:22 PDT
Date: 18 Jun 86 11:23:00 EST
From: "BIZET::BUY" <buy%bizet.decnet@hudson.dec.com>
Subject: packages and portability
To: "common-lisp" <common-lisp@su-ai.arpa>
Reply-To: "BIZET::BUY" <buy%bizet.decnet@hudson.dec.com>
This message is in reply to two previous messages by John Foderaro
about packages and portability.
> >> In summary, I
> >> think that the most reliable way to deal with white page extended
> >> objects is to provide two distinct definitions, one for each of the
> >> two packages. Although double definitions may not appear to be
> >> necessary for the time being and may be tedious to implement, I think
> >> that they should not be precluded a priori from future
> >> implementations.
>
> We agree that double definitions aren't needed now and would be
> tedious to implement. I personally feel that they are also too
> dangerous. If it was determined that adding something like the
> :cross-reference argument to compile-file was an illegal extension,
> then I would rather create a new function (excl:excl-compile-file) than
> create a double definition for compile-file.
>
> What extensions do you see in the future that would make double
> definitions necessary?
>
> -john foderaro
> franz inc.
>
I think that site specific extensions may be of various kinds. For
example, the VAX LISP implementation of FORMAT includes 8 directives in
addition to those specified in CLtL. In the same implementation,
APROPOS and APROPOS-LIST make use of DO-SYMBOLS rather than
DO-ALL-SYMBOLS, as specified in CLtL. In ZETALISP the special form IF
can take more than three arguments and arguments after the second are
assumed to be the ELSE clause with an implicit PROGN. Other kinds of
site specific extensions are additional keyword arguments to CLtL
functions, additional values returned by CLtL functions, extensions to
valid input argument types for CLtL functions.
Let us assume that 'X' is a symbol whose CLtL definition was extended
by a particular implementation of Common LISP and let us consider the
issue of what package should contain X. If X is contained in the
extended package only (for portability), the pure Common LISP package
will be incomplete with respect to the specification in CLtL.
Conversely, if X is contained in the pure Common LISP package (for
completeness of an implementation), users may end up inadvertently
using site specific extensions and thus writing non-portable code.
Consequently, the approach of providing two distinct implementations
for certain extended CLtL objects may facilitate writing portable code.
> ... let's step back and look at the big
> picture. The DEC proposal and our proposal are trying to solve the same
> problem: creation of a lisp system in which is possible to write portable
> programs as well as implementation specific (non-portable) program.
>
> ....
>
> Under both proposals it is easy to write portable code. To verify that
> your code is portable you really have to check your source to see if
> you've used any extensions. Under the DEC proposal the system will
> catch non-portabilities in the CLtL functions as the code is running,
> but of course it won't catch them all unless you exercise every path of
> the code. In the ExCL proposal you have to take the handy 'extensions
> sheet' and check by hand that you haven't used any extensions. Of
> course, the careful programmer will simply not use extensions in
> portable code.
>
> ...
>
> Under the ExCL proposal it is simple and natural to switch between the
> extended and portable modes. Under the DEC proposal the procedure is
> more difficult.
>
> The ExCL proposal shows off the power of the package system in the ability
> to easily move into and out of the extended environment. The DEC
> proposal shows off one of the big misfeatures of the package system:
> that you have to go to so much trouble if you merely want to shadow
> one symbol in the lisp package. Do we want users to emulate this
> kind of package construction?
>
In our opinion, the model we proposed represents a reasonable
compromise between ease of use and flexibility. I don't think that the
procedure to switch between the extended and the portable environment
is so difficult as to constitute a serious drawback (see my previous
messages about this). Moreover, the model deals uniformly with double
definitions for objects defined in CLtL. In addition, this model
supports effectively writing portable code. I obviously agree about the
fact that run-time checks for portable code are indeed useful.
Compile-time checks may contribute even more significantly to the
detection of non-portable code.
> If we ever want to do double definitions in the future, then the DEC
> proposal sets up the framework. The ExCL proposal doesn't prevent
> double definitions but it doesn't set it up either. If double
> definitions will be important in the future in order to implement
> extensions then we should be able to come up with a few examples
> where they would be important. I can't think of any. As I see it,
> either the extension is so trivial you can add it to the standard
> definition, or the extension is so large thfunction to avoid confusion.
In our opinion, the Franz proposal indeed renders double definitions
substantially more inconvenient to use when trying to switch from a
pure Common LISP to an extended environment and vice versa. I discussed
the reason for this in a previous message.
Thanks for your attention and again sorry for the length of this
message,
Ugo Buy
ARPAnet: BUY%BARTOK.DEC@DECWRL.ARPA
------
∂18-Jun-86 0905 REM@IMSSS Achieving portability, how?
Received: from IMSSS by SU-AI with PUP; 18-Jun-86 09:04 PDT
Date: 18 Jun 1986 0903-PDT
From: Rem@IMSSS
Subject: Achieving portability, how?
To: COMMON-LISP@SU-AI
There seem to be several ways to achieve portability:
(1) Require every implementation to provide a pure-COMMON-LISP package
that has no extensions. If a program runs in this it will run anywhere.
(2) Require one master host to provide a pure-COMMON-LISP package.
Everyone wishing to test portability must FTP the program to that host
and test portability there.
(3) Provide tools for examining the text (source) of a program and reporting
any non-portable syntax. These tools could be used anywhere.
(4) Provide hardcopy documentation as to what may be an extension in any
given implementation, but leave it to users to manually search their files
for such non-portable usage.
The recent concensus seems to be a combination of (1) and (4). Provide
a pure-COMMON-LISP package, but it may contain extra keyword arguments
beyond the spec, so users still have to manually search the manual for
this documentation and then manually search their programs for usage of
the extra stuff.
I think (4) in any signifincant amount is unacceptable. Either require
the pure-COMMON-LISP package to be identically the CLtL with no extensions
whatsoever, or use (3) instead of (4) to check for the exceptions;
or use (3) from the start with no deliberate exceptions. Of course there
will be some non-portable code that looks portable, nothing is perfect,
but an automated means that is as close to perfect portability-testing as
the state of the art permits should be our goal, instead of some half-baked
idea that is known from the start to be flawed in many ways.
(Opinion of REM%IMSSS@SU-AI)
-------
∂18-Jun-86 1228 @MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA Re: Out-of-range subsequences
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 12:28:22 PDT
Received: from MIT-CHERRY.ARPA by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 2798; Wed 18-Jun-86 15:30:07-EDT
Date: Wed, 18 Jun 86 15:28 EDT
From: Soley@MIT-XX.ARPA
Subject: Re: Out-of-range subsequences
To: preece%ccvaxa@GSWD-VMS.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: <8606181414.AA11649@gswd-vms.ARPA>
Message-ID: <860618152801.2.SOLEY@MIT-CHERRY.ARPA>
Message-Id: <8606181414.AA11649@gswd-vms.ARPA>
Date: Wed, 18 Jun 86 09:14:35 cdt
From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: Out-of-range subsequences
>
> From: Daniels.pa@Xerox.COM
>
> In particular, is (subseq #(1 2 3) 0 5) an error?
----------
If you clarify it to require and in bounds endpoint, you need
to do two operations.
So what, it's only (subseq a 0 (min 5 (length a))).
No big deal, but I don't think many
users would find it confusing that the operation stops at
end of string if the endpoint is out of bounds.
I think they would. (subseq a 0 5) should always return a string of
length 5. Under your scheme, it might return a shorter string.
-- Richard
∂18-Jun-86 1300 DLW@RIVERSIDE.SCRC.Symbolics.COM Re: Out-of-range subsequences
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 13:00:21 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25514; Wed 18-Jun-86 15:58:41 EDT
Date: Wed, 18 Jun 86 16:01 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Out-of-range subsequences
To: preece%ccvaxa@GSWD-VMS.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: <8606181414.AA11649@gswd-vms.ARPA>
Message-ID: <860618160109.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
It's not a question of pickiness, but one of consistency. Common Lisp
takes a uniform attitude about addressing outside the boundaries of an
array, and all functions should follow the convention.
∂18-Jun-86 1345 franz!fimass!jkf@kim.Berkeley.EDU Re: packages and portability
Received: from [128.32.130.7] by SU-AI.ARPA with TCP; 18 Jun 86 13:45:25 PDT
Received: by kim.Berkeley.EDU (5.51/1.14)
id AA05061; Wed, 18 Jun 86 13:45:44 PDT
Received: from fimass by franz (5.5/3.14)
id AA03704; Wed, 18 Jun 86 11:40:28 PDT
Received: by fimass (5.5/3.14)
id AA19280; Wed, 18 Jun 86 10:38:28 PST
From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro)
Return-Path: <fimass!jkf>
Message-Id: <8606181838.AA19280@fimass>
To: "BIZET::BUY" <ucbkim!hudson.dec.com!buy%bizet.decnet>
Cc: common-lisp@su-ai.arpa
Subject: Re: packages and portability
In-Reply-To: Your message of 18 Jun 86 11:23:00 EST.
<8606181548.AA28606@kim.Berkeley.EDU>
Date: Wed, 18 Jun 86 10:38:22 PST
>> I think that site specific extensions may be of various kinds. For
>> example, the VAX LISP implementation of FORMAT includes 8 directives in
>> addition to those specified in CLtL.
This is an upward compatible change and doesn't force double definitions.
>> In the same implementation,
>> APROPOS and APROPOS-LIST make use of DO-SYMBOLS rather than
>> DO-ALL-SYMBOLS, as specified in CLtL.
This is a good example of the kind of extensions we want to avoid. It
isn't upward compatible and it is only going to confuse the poor user
who is trying to program in common lisp using CLtL. Why not choose
other names for your apropos functions?
>> In ZETALISP the special form IF
>> can take more than three arguments and arguments after the second are
>> assumed to be the ELSE clause with an implicit PROGN.
I also dislike the common lisp 'if' special form, but rather than modify
it, I wrote a new macro, and gave it the name 'if*'. In your case
I would suggest something similar. I don't like typing 'if*' when
I really mean 'if', but the benefits far outweigh this inconvenience.
Besides, now code using 'if*' can be ported as long as I carry along
the definition of my if* macro.
>> ...
>> Consequently, the approach of providing two distinct implementations
>> for certain extended CLtL objects may facilitate writing portable code.
I disagree only slightly with this: you can write portable code
regardless of the package layout, where your package setup helps is in testing
for non-portableness (both by compiling the code and running it).
But as the saying goes, "Testing only proves the presence of bugs, not the
absence", thus we agree that it would be foolish to use this as
the only mechanism to test for portability.
And how can one ever test whether the user is using the correct
version of 'apropos' in your system? The previous sentence is perhaps
the key point: unless we can agree to assign one meaning to each of
the functions in common lisp, how can we ever achieve portability?
If the presence of double definitions is a license to change CLtL
functions at will, then I would be against using double definitions
for that reason alone.
-john foderaro
franz inc.
∂18-Jun-86 1537 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Unsolicited typeout
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jun 86 14:13:01 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24980; Wed 18-Jun-86 17:04:00 EDT
Date: Wed, 18 Jun 86 17:02 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Unsolicited typeout
To: COMMON-LISP@SU-AI.ARPA
Message-ID: <860618170258.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I have a problem about functions doing unsolicited typeout. The manual
is somewhat silent on this issue and the next edition should make its
intent more clear. For example, the manual makes no statement about
whether CONS or EQUAL does typeout, but I hope we agree that it's not
a good idea for them to do so. I think the manual should be tightened
up in this regard.
VAXLISP 1.2 (for example) outputs "FOO compiled." every time COMPILE
or COMPILE-FILE compiles something. Symbolics' Common Lisp (for example)
does not. This is very problemsome if I want a program that secretly
compiles things to have identical I/O behavior in both systems.
I suppose I could bind *STANDARD-OUTPUT* around calls to COMPILE but
that seems a little silly. And besides, VAXLISP 1.2 outputs compiler
warnings to *STANDARD-OUTPUT* rather than *ERROR-OUTPUT*, so I'd also
miss warnings if I bound *STANDARD-OUTPUT* (something that wouldn't
happen in Symbolics' Common Lisp).
I can't call these bugs in VAXLISP, because the manual doesn't say that
COMPILE doesn't do typeout to *STANDARD-OUTPUT*. Nor does it say that
COMPILE is obliged to call WARN (or even to simulate its behavior)
when reporting problems. Nevertheless, I hope that a future standard
will be written in such a way that things like this could be treated
as simple bugs.
In general, I feel that the next edition of the manual should make
it very clear that certain kinds of actions (such as output to
*STANDARD-OUTPUT*) are implicitly forbidden unless there is an explicit
statement to the contrary. The same text should also expressly allow
anything to do output to *ERROR-OUTPUT* at any time, since that can
be safely bound to something else in contexts where warnings need to
be suppressed without affecting the "normal" I/O behavior of the
program in question.
By the way, I get tired of writing
(WITH-OUTPUT-TO-STRING (*STANDARD-OUTPUT*)
...)
around things that I want to portably suppress output from (and then
throwing away the result string). It's inefficient and doesn't say
what I mean. In the absence of a protocol for making generalized
user-defined streams, I would like very much if we would provide a
WITH-OUTPUT-DISCARDED special form (or macro) that would say and do
what I really mean to be doing. Alternatively, if there were a
variable that held a stream that did this output and I could do
(LET ((*STANDARD-OUTPUT* *NULL-OUTPUT-STREAM*)) ...), that would
suffice.
I might be ammenable to a new stream, *WINDY-OUTPUT* which was a
stream to which "extra" output could be sent in situations where
extra-verbose output might or might not be allowed. I'd have to study
this in more detail before committing to it, but I thought I'd note
the idea. eg, COMPILE and COMPILE-FILE mentioned above might could
use this, and also LOAD (which I complained in earlier mail types
out the name of every function loaded in some implementations but
not in others). I'm not sure if we could make this rigorous enough
to be useful, but at least people could bind *WINDY-OUTPUT* to
*NULL-OUTPUT-STREAM*.
∂18-Jun-86 1537 preece%ccvaxa@gswd-vms.ARPA Re: Out-of-range subsequences
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 13:56:12 PDT
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/)
id AA12065; Wed, 18 Jun 86 15:55:19 CDT
Message-Id: <8606182055.AA12065@gswd-vms.ARPA>
Date: Wed, 18 Jun 86 15:54:21 cdt
From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: Out-of-range subsequences
> It's not a question of pickiness, but one of consistency. Common Lisp
> takes a uniform attitude about addressing outside the boundaries of an
> array, and all functions should follow the convention. From: Daniel L.
> Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
----------
Well, if your clarify the definition to say that subsequences
end at the end of the underlying sequence, then you're NOT
addressing outside the boundaries of the array. However,
I'm changing our implementation, even as we speak, to signal
an error, since that seems to be the consensus.
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
∂18-Jun-86 1538 gls@Think.COM Out-of-range subsequences
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 18 Jun 86 14:48:10 PDT
Received: from wenceslas by Godot.Think.COM via CHAOS; Wed, 18 Jun 86 17:47:35 edt
Date: Wed, 18 Jun 86 17:48 EDT
From: Guy Steele <gls@Think.COM>
Subject: Out-of-range subsequences
To: DLW@QUABBIN.SCRC.Symbolics.COM, Daniels.pa@Xerox.COM,
common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860618082448.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <860618174850.1.GLS@WENCESLAS.THINK.COM>
Date: Wed, 18 Jun 86 08:24 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Date: 17 Jun 86 14:43 PDT
From: Daniels.pa@Xerox.COM
In particular, is (subseq #(1 2 3) 0 5) an error?
What an excellent example of the sort of thing that the manual really
needs to be more explicit about.
Our implementation signals an error. It certainly seems to me
that it ought to.
About the best I have to offer is that the manual says that
start and end "should be integer indices into the sequence".
I would interpret "into the sequence" and meaning "between 0 and
the length of the sequence, inclusive", but I grant that there is
considerable latitude for controversy here.
--Guy
∂18-Jun-86 1620 preece%ccvaxa@gswd-vms.ARPA Re: Out-of-range subsequences
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 13:56:12 PDT
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/)
id AA12065; Wed, 18 Jun 86 15:55:19 CDT
Message-Id: <8606182055.AA12065@gswd-vms.ARPA>
Date: Wed, 18 Jun 86 15:54:21 cdt
From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: Out-of-range subsequences
> It's not a question of pickiness, but one of consistency. Common Lisp
> takes a uniform attitude about addressing outside the boundaries of an
> array, and all functions should follow the convention. From: Daniel L.
> Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
----------
Well, if your clarify the definition to say that subsequences
end at the end of the underlying sequence, then you're NOT
addressing outside the boundaries of the array. However,
I'm changing our implementation, even as we speak, to signal
an error, since that seems to be the consensus.
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
∂18-Jun-86 1636 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Achieving portability, how?
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jun 86 16:21:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25142; Wed 18-Jun-86 18:47:39 EDT
Date: Wed, 18 Jun 86 18:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Achieving portability, how?
To: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 18 Jun 86 12:03 EDT from Rem@IMSSS
Message-ID: <860618184650.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
In reply to REM's message:
I thought the goals of Common Lisp were as stated on the first three
(arabic-numbered) pages of the manual, whereas you are calling for
Common Lisp to be a collection of very-close-to-identical
implementations on a wide variety of machines, with portability
virtually guaranteed. That would probably be a useful thing to have, at
least if it were free, but it's a big change of direction and ought to
be discussed as a change of direction rather than as an obvious
clarification of what we were doing all along.
∂18-Jun-86 1639 MILNES%cgi.csnet@CSNET-RELAY.ARPA Argument Lists
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 16:39:47 PDT
Received: from cgi by csnet-relay.csnet id aa29386; 18 Jun 86 19:30 EDT
Date: Wed, 18 Jun 86 19:17 ???
From: MILNES%cgi.csnet@CSNET-RELAY.ARPA
To: common-lisp@SU-AI.ARPA
Subject: Argument Lists
From: Brian Milnes @cgi.csnet.com
We here at CGI have run into several cases where we would
like to be able to access the argument list format for functions and
macros in a system independent manner. The symbolics and the TI support
a function arglist which returns the lambda list for a function; we
are using this to provide a command like ctr-A, which describes a
functions argument list, in Knowledge Craft.
I also would like a Common Lisp way of determining the minimum
and maximum number of arguments taken by a given function; this would
allow the CRL-OPS compiler to determine a left hand side predicate
call has the correct number of arguments so that it does not cause
an error and leave the RETE pattern matching network in an inconsistent
state.
Have we missed this functionality in CLtL ? Do others of you
out there miss this functionality ? Could it be simply and safely
added to CL ?
-Brian
∂18-Jun-86 1708 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Unsolicited typeout
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jun 86 14:13:01 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24980; Wed 18-Jun-86 17:04:00 EDT
Date: Wed, 18 Jun 86 17:02 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Unsolicited typeout
To: COMMON-LISP@SU-AI.ARPA
Message-ID: <860618170258.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I have a problem about functions doing unsolicited typeout. The manual
is somewhat silent on this issue and the next edition should make its
intent more clear. For example, the manual makes no statement about
whether CONS or EQUAL does typeout, but I hope we agree that it's not
a good idea for them to do so. I think the manual should be tightened
up in this regard.
VAXLISP 1.2 (for example) outputs "FOO compiled." every time COMPILE
or COMPILE-FILE compiles something. Symbolics' Common Lisp (for example)
does not. This is very problemsome if I want a program that secretly
compiles things to have identical I/O behavior in both systems.
I suppose I could bind *STANDARD-OUTPUT* around calls to COMPILE but
that seems a little silly. And besides, VAXLISP 1.2 outputs compiler
warnings to *STANDARD-OUTPUT* rather than *ERROR-OUTPUT*, so I'd also
miss warnings if I bound *STANDARD-OUTPUT* (something that wouldn't
happen in Symbolics' Common Lisp).
I can't call these bugs in VAXLISP, because the manual doesn't say that
COMPILE doesn't do typeout to *STANDARD-OUTPUT*. Nor does it say that
COMPILE is obliged to call WARN (or even to simulate its behavior)
when reporting problems. Nevertheless, I hope that a future standard
will be written in such a way that things like this could be treated
as simple bugs.
In general, I feel that the next edition of the manual should make
it very clear that certain kinds of actions (such as output to
*STANDARD-OUTPUT*) are implicitly forbidden unless there is an explicit
statement to the contrary. The same text should also expressly allow
anything to do output to *ERROR-OUTPUT* at any time, since that can
be safely bound to something else in contexts where warnings need to
be suppressed without affecting the "normal" I/O behavior of the
program in question.
By the way, I get tired of writing
(WITH-OUTPUT-TO-STRING (*STANDARD-OUTPUT*)
...)
around things that I want to portably suppress output from (and then
throwing away the result string). It's inefficient and doesn't say
what I mean. In the absence of a protocol for making generalized
user-defined streams, I would like very much if we would provide a
WITH-OUTPUT-DISCARDED special form (or macro) that would say and do
what I really mean to be doing. Alternatively, if there were a
variable that held a stream that did this output and I could do
(LET ((*STANDARD-OUTPUT* *NULL-OUTPUT-STREAM*)) ...), that would
suffice.
I might be ammenable to a new stream, *WINDY-OUTPUT* which was a
stream to which "extra" output could be sent in situations where
extra-verbose output might or might not be allowed. I'd have to study
this in more detail before committing to it, but I thought I'd note
the idea. eg, COMPILE and COMPILE-FILE mentioned above might could
use this, and also LOAD (which I complained in earlier mail types
out the name of every function loaded in some implementations but
not in others). I'm not sure if we could make this rigorous enough
to be useful, but at least people could bind *WINDY-OUTPUT* to
*NULL-OUTPUT-STREAM*.
∂18-Jun-86 1721 gls@Think.COM Out-of-range subsequences
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 18 Jun 86 14:48:10 PDT
Received: from wenceslas by Godot.Think.COM via CHAOS; Wed, 18 Jun 86 17:47:35 edt
Date: Wed, 18 Jun 86 17:48 EDT
From: Guy Steele <gls@Think.COM>
Subject: Out-of-range subsequences
To: DLW@QUABBIN.SCRC.Symbolics.COM, Daniels.pa@Xerox.COM,
common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860618082448.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <860618174850.1.GLS@WENCESLAS.THINK.COM>
Date: Wed, 18 Jun 86 08:24 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Date: 17 Jun 86 14:43 PDT
From: Daniels.pa@Xerox.COM
In particular, is (subseq #(1 2 3) 0 5) an error?
What an excellent example of the sort of thing that the manual really
needs to be more explicit about.
Our implementation signals an error. It certainly seems to me
that it ought to.
About the best I have to offer is that the manual says that
start and end "should be integer indices into the sequence".
I would interpret "into the sequence" and meaning "between 0 and
the length of the sequence, inclusive", but I grant that there is
considerable latitude for controversy here.
--Guy
∂18-Jun-86 1954 NGALL@G.BBN.COM Re: Unsolicited typeout
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 19:53:52 PDT
Date: 18 Jun 1986 22:52-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Unsolicited typeout
From: NGALL@G.BBN.COM
To: KMP@SCRC-STONY-BROOK.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Message-ID: <[G.BBN.COM]18-Jun-86 22:52:08.NGALL>
In-Reply-To: <860618170258.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 18 Jun 86 17:02 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
To: COMMON-LISP@SU-AI.ARPA
Subject: Unsolicited typeout
Message-ID: <860618170258.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
...
In general, I feel that the next edition of the manual should make
it very clear that certain kinds of actions (such as output to
*STANDARD-OUTPUT*) are implicitly forbidden unless there is an explicit
statement to the contrary. The same text should also expressly allow
anything to do output to *ERROR-OUTPUT* at any time, since that can
be safely bound to something else in contexts where warnings need to
be suppressed without affecting the "normal" I/O behavior of the
program in question.
Agreed.
By the way, I get tired of writing
(WITH-OUTPUT-TO-STRING (*STANDARD-OUTPUT*)
...)
around things that I want to portably suppress output from (and then
throwing away the result string). It's inefficient and doesn't say
what I mean. In the absence of a protocol for making generalized
user-defined streams, I would like very much if we would provide a
WITH-OUTPUT-DISCARDED special form (or macro) that would say and do
what I really mean to be doing. Alternatively, if there were a
variable that held a stream that did this output and I could do
(LET ((*STANDARD-OUTPUT* *NULL-OUTPUT-STREAM*)) ...), that would
suffice.
How 'bout
(defvar *null-output-stream* (make-broadcast-stream))
-- Nick
∂18-Jun-86 2009 NGALL@G.BBN.COM Structure sharing
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 20:09:22 PDT
Date: 18 Jun 1986 23:08-EDT
Sender: NGALL@G.BBN.COM
Subject: Structure sharing
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]18-Jun-86 23:08:42.NGALL>
KCL recently surprised me with the following behavior:
(setf foo 'filename) => FILENAME
(setf bar (namestring foo)) => "FILENAME"
(setf bar (nstring-downcase bar)) => "filename"
foo => {causes error}
It seems that in KCL. namestring of a symbol merely returns a
simple-string whose characters are SHARED with the print-name of the
symbol FILENAME!
As far as I can tell, this kind of sharing is perfectly legit, even
though it is very unintuitive. Even parse-namestring returns a
pathname that shares characters with the string it was given!
I think it would be a good idea for CLtL to explicity state that
unless otherwise noted, a given function may return an object that
shares structure with another object. And it would help to give a few
examples like parse-namestring and namestring to point out the
non-obvious consequences.
-- Nick
∂18-Jun-86 2029 FAHLMAN@C.CS.CMU.EDU What are special forms?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jun 86 20:29:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 18 Jun 86 23:29:14-EDT
Date: Wed, 18 Jun 1986 23:29 EDT
Message-ID: <FAHLMAN.12215948482.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: What are special forms?
In-reply-to: Msg of Tue 17 Jun 86 19:27:09+0900 from nttlab!kurims!yuasa at kurims.kurims.kyoto-u.junet
In response to: nttlab!kurims!yuasa at kurims.kurims.kyoto-u.junet
This issue was discussed on Common Lisp some time ago, perhaps before
the network connections to Japan were working.
We had all fallen into the habit of using the term "special form" to
refer to both the entire form and the symbol (such as SETQ) that names
the form. Someone pointed out that this was sloppy and potentially
confusing. He proposed that we refer to the symbol as a "special
operator", reserving the name "special form" for the entire list.
This seemed like a good clarification to all of us, but there was some
disagreement about whether the potential for confusion was great enough
to justify changing the name SPECIAL-FORM-P to SPECIAL-OPERATOR-P.
This was never resolved. It is on my list of things that we need to
settle.
So what my message meant to say was that (Compiled-Function-P 'setq) =>
nil.
Incidentally, I would like to ask you what "globally" means in
the following sentence in the CLtL description of SPECIAL-FORM-P in
Page 91.
If the symbol globally names a special form, ....
I beleive that the word "globally" is superfluous in this sentence. At
one time it was contemplated that forms like FLET might locally redefine
symbols that are special-forms (menaing special operators) at top level.
I believe that the manual now says explicitly that it is illegal to
redefine special forms, though I can't find that pasage right now.
-- Scott
∂18-Jun-86 2037 FAHLMAN@C.CS.CMU.EDU Structure sharing
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jun 86 20:36:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 18 Jun 86 23:35:07-EDT
Date: Wed, 18 Jun 1986 23:35 EDT
Message-ID: <FAHLMAN.12215949545.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Structure sharing
In-reply-to: Msg of 18 Jun 1986 23:08-EDT from NGALL at G.BBN.COM
Page 168:
"It is an extremely bad idea to modify a string being used as the print
name of a symbol. Such a modification may tremendously confuse the
function READ and the package system."
∂18-Jun-86 2041 preece%ccvaxa@gswd-vms.ARPA Unsolicited typeout
Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 20:40:59 PDT
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/)
id AA12295; Wed, 18 Jun 86 22:40:09 CDT
Message-Id: <8606190340.AA12295@gswd-vms.ARPA>
Date: Wed, 18 Jun 86 22:38:31 cdt
From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Unsolicited typeout
> VAXLISP 1.2 (for example) outputs "FOO compiled." every time COMPILE
> or COMPILE-FILE compiles something. Symbolics' Common Lisp (for
> example) does not. This is very problemsome if I want a program that
> secretly compiles things to have identical I/O behavior in both
> systems.
> From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
----------
I don't know for certain about VAXLISP, but since it's a Spice
derivative you might try setting *verbose* (maybe that's
compiler::*verbose*) to NIL. That specifically turns off
compiler progress messages.
--
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece
∂18-Jun-86 2106 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Structure sharing
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jun 86 21:06:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25327; Thu 19-Jun-86 00:05:24 EDT
Date: Thu, 19 Jun 86 00:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Structure sharing
To: NGALL@G.BBN.COM, Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]18-Jun-86 23:08:42.NGALL>,
<FAHLMAN.12215949545.BABYL@C.CS.CMU.EDU>
Message-ID: <860619000135.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 18 Jun 1986 23:08-EDT
From: NGALL@G.BBN.COM
KCL recently surprised me with the following behavior:
(setf foo 'filename) => FILENAME
(setf bar (namestring foo)) => "FILENAME"
(setf bar (nstring-downcase bar)) => "filename"
foo => {causes error}
It seems that in KCL. namestring of a symbol merely returns a
simple-string whose characters are SHARED with the print-name of the
symbol FILENAME!
Date: Wed, 18 Jun 1986 23:35 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Page 168:
"It is an extremely bad idea to modify a string being used as the print
name of a symbol. Such a modification may tremendously confuse the
function READ and the package system."
Does this tell us whether the behavior of NAMESTRING in KCL is valid
or invalid? I think it's valid, but nothing in the manual directly
supports that claim.
From: NGALL@G.BBN.COM again
I think it would be a good idea for CLtL to explicity state that
unless otherwise noted, a given function may return an object that
shares structure with another object. And it would help to give a few
examples like parse-namestring and namestring to point out the
non-obvious consequences.
It sounds like the agenda of language clarifications ought to include
such an item.
∂18-Jun-86 2133 kddlab!yuasa@kurims.kurims.kyoto-u.junet What are special forms?
Received: from seismo.CSS.GOV by SU-AI.ARPA with TCP; 18 Jun 86 21:33:03 PDT
Received: from kddlab.UUCP by seismo.CSS.GOV with UUCP; Thu, 19 Jun 86 00:01:35 EDT
From: kddlab!yuasa@kurims.kurims.kyoto-u.junet
Received: by kddlabs.junet ; Wed, 18 Jun 86 18:33:58+0900
Return-Path: <kddlab!yuasa@kurims.kurims.kyoto-u.junet>
Received: by kddlabs.junet ; Wed, 18 Jun 86 18:33:46+0900
Received: by titan.junet (4.12/6.0Junet)
id AA00768; Wed, 18 Jun 86 15:58:05 jst
Received: by nttlab.ntt.junet (4.12/4.7JC-7) with TCP
id AA28412; Wed, 18 Jun 86 12:31:20 jst
Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet)
id AA00861; Tue, 17 Jun 86 19:27:09+0900
Date: Tue, 17 Jun 86 19:27:09+0900
Message-Id: <8606171027.AA00861@kurims.kurims.kyoto-u.junet>
To: nttlab!Shasta!Fahlman@C.CS.CMU.EDU
Subject: What are special forms?
Cc: common-lisp@SU-AI.ARPA
I have been worrying about what are meant by "special forms".
CLtL defines, in Page 56, that
If the first element (of a list form) is one of the
symbols appearing in Table 5-1, then the list is called
a /special form/.
According to this definition, (SETQ X 1) is a special form but
the symbol SETQ is not. Indeed, the caption of Table 5-1 (page 57)
explicitly says that the table lists *Names* of Common Lisp
special forms. Thus, SETQ certainly is a symbol that names special
forms such as (SETQ X 1) and (SETQ).
So far, so good.
Right below Table 5-1, CLtL says
The set of special forms is fixed ....
This is still OK. The set of special forms consists of infinite
number as its elements, but anyway it is fixed. However, in the next
paragraph, it says
The set of special forms is kept very small ...
Small (!!!) an infinite set is ??? The sentense should rather be
The set of special form names is kept very small ...
The name SPECIAL-FORM-P enlarges such a kind of confusion between
special forms and special form names. The name of the function should
rather be SPECIAL-FORM-NAME-P or something like that. I am writing
this message because I really got confused to read the following message.
Date: Mon, 16 Jun 1986 22:52 EDT
From: "Scott E. Fahlman"
....
There's no such thing as a FEXPR in Common Lisp, though some
implementations may use such a thing internally in implementing specia
forms. I'll assume that you mean "special form" or "special operator"
or whatever we are calling it. I think that Compiled-Function-P and
Function-P should answer NIL for special forms.
Does this mean, for example,
(COMPILED-FUNCTION-P '(SETQ X 1)) => NIL
(FUNCTION-P '(SETQ X 1)) => NIL
or
(COMPILED-FUNCTION-P (SPECIAL-FORM-P 'SETQ)) => NIL
(FUNCTION-P (SPECIAL-FORM-P 'SETQ)) => NIL
?
The latter interpretation seems to contradict CLtL, which says
A returned non-NIL value (of SPECIAL-FORM-P) is typically a function
of ...
Incidentally, I would like to ask you what "globally" means in
the following sentence in the CLtL description of SPECIAL-FORM-P in Page 91.
If the symbol globally names a special form, ....
I am sorry if there still is a sort of consensus in US Lisp people in this
issue. But please keep it in mind that CLtL and common-lisp@su-ai are
the only references to me.
-- Taiichi
∂19-Jun-86 0003 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (MAKE-BROADCAST-STREAM)
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 19 Jun 86 00:02:58 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25367; Thu 19-Jun-86 03:02:04 EDT
Date: Thu, 19 Jun 86 03:00 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: (MAKE-BROADCAST-STREAM)
To: NGALL@G.BBN.COM
cc: COMMON-LISP@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA
Message-ID: <860619030046.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Calling (MAKE-BROADCAST-STREAM) to make a null output stream is about
as perspicuous as doing (APPEND X '()) to COPY-LIST X... which may
account for why I hadn't thought to do it. In spite of its grunginess,
it does at least satisfy my need (if not my want). So perhaps we could
still think about offering *NULL-OUTPUT-STREAM* or some such to free
some people from the need to be so clever.
... reminds me, though. I wouldn't mind it if CL offered COPY-STRING
and maybe even COPY-CONS -- again for the sake of perspicuity.
∂19-Jun-86 0023 DT50@A.CS.CMU.EDU out-of-range subsequences
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jun 86 15:00:34 PDT
Date: 18 Jun 86 17:57 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
To: common-lisp@SU-AI.ARPA
Subject: out-of-range subsequences
CC: Dave Touretzky@A.CS.CMU.EDU
I think (SUBSEQ s x y) should only return an error if x<0 or y<0. I see no
reason to force an expression like (SUBSEQ #(a b c) 0 9) to return an error
when it could return a perfectly useful value instead.
Here are two more arguments against returning an error. First, whether or
not SUBSEQ returns an error, it still has to check the length of the sequence
in order to do the right thing. So if we force the user to write
(SUBSEQ x 0 (min 5 (length x))) the length gets checked twice: once by the
user code, and once by SUBSEQ. This seems wasteful.
The second argument is that for lists, there is already precedent for
permitting out of range indexing, e.g. (NTH '(a b c) 7) returns NIL rather
than an error. I don't object to ELT returning an error in this case because
there's no more natural thing to do in the case of vectors. (Consing up an
returning a new empty vector would be a dumb idea.) But in the case of
SUBSEQ there is a perfectly good behavior, namely, return as much of the
sequence as actually exists.
-- Dave
∂19-Jun-86 0744 Larry←Masinter.PARC@Xerox.COM Re: (MAKE-BROADCAST-STREAM)
Received: from XEROX.COM by SU-AI.ARPA with TCP; 19 Jun 86 07:43:59 PDT
Received: from Burger.ms by ArpaGateway.ms ; 19 JUN 86 07:29:10 PDT
Sender: "Larry←Masinter.PARC"@Xerox.COM
Date: 19 Jun 86 07:24:45 PDT (Thursday)
Subject: Re: (MAKE-BROADCAST-STREAM)
From: masinter.PARC@Xerox.COM
To: KMP@SCRC-STONY-BROOK.Arpa
cc: NGALL@G.BBN.COM, COMMON-LISP@SU-AI.Arpa, KMP@SCRC-STONY-BROOK.Arpa
In-Reply-to: KMP%SCRC-STONY-BROOK:ARPA's message of Thursday, June 19,
1986 12:25 am
Reply-to: masinter.PARC@Xerox.COM
Message-ID: <860619-072910-1230@Xerox>
*discard-output-stream* is more descriptive, even to those who are used
to NUL: and /dev/nul/ and the like.
∂19-Jun-86 0825 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM out-of-range subsequences
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 19 Jun 86 08:24:17 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25632; Thu 19-Jun-86 11:22:27 EDT
Date: Thu, 19 Jun 86 11:25 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: out-of-range subsequences
To: Dave.Touretzky@CMU-CS-A.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 18 Jun 86 17:57 EDT from Dave.Touretzky@A.CS.CMU.EDU
Message-ID: <860619112526.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 18 Jun 86 17:57 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
I think (SUBSEQ s x y) should only return an error if x<0 or y<0. I see no
reason to force an expression like (SUBSEQ #(a b c) 0 9) to return an error
when it could return a perfectly useful value instead.
To take a simple function and then make its definition inconsistent with
the spirit of the language, just to squeeze in an extra feature, is the
way to make the language inconsistent and hard to learn.
Here are two more arguments against returning an error. First, whether or
not SUBSEQ returns an error, it still has to check the length of the sequence
in order to do the right thing. So if we force the user to write
(SUBSEQ x 0 (min 5 (length x))) the length gets checked twice: once by the
user code, and once by SUBSEQ. This seems wasteful.
To take a simple function and then make its definition inconsistent with
the spirit of the language, just to save a few microseconds, is another
way to make the language inconsistent and hard to learn.
The second argument is that for lists, there is already precedent for
permitting out of range indexing, e.g. (NTH '(a b c) 7) returns NIL rather
than an error.
But there is no such precedent for arrays, nor for sequences in general.
NTH, unfortunately, needs to behave that way for consistency, on the
grounds that one would expect that NTH could be defined the obvious way
using CAR and CDR, and CAR and CDR both return NIL when given NIL.
(Indeed, the whole business of CAR of NIL was one of those features
shoehorned into the language for a little extra convenience, at the cost
of consistency. As we used to say at MIT about TECO macros: "A moment
of convenience; a lifetime of regret.")
∂19-Jun-86 0838 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM (MAKE-BROADCAST-STREAM)
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 19 Jun 86 08:37:52 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25649; Thu 19-Jun-86 11:32:20 EDT
Date: Thu, 19 Jun 86 11:35 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: (MAKE-BROADCAST-STREAM)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <860619030046.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <860619113522.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 19 Jun 86 03:00 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
... reminds me, though. I wouldn't mind it if CL offered COPY-STRING
and maybe even COPY-CONS -- again for the sake of perspicuity.
I believe that the intention was that COPY-SEQ was sufficiently
perspicuous for copying strings. I presume it was assumed that
COPY-LIST and COPY-TREE were what people needed the most often, and
COPY-CONS wasn't something that would be needed so often to justify
specific inclusion of such a function given that it's easy to write
yourself. (A lot of value judgements, about which things would be
sufficiently useful to so many people that having it pre-included in the
language, had to be made during the design of the language; naturally
there's no single right answer in any particular case.)
∂19-Jun-86 1303 Masinter.pa@Xerox.COM Re: Why aren't char bits portable?
Received: from XEROX.COM by SU-AI.ARPA with TCP; 19 Jun 86 13:03:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 JUN 86 12:38:48 PDT
Date: 19 Jun 86 12:32 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Why aren't char bits portable?
To: common-lisp@su-ai.ARPA
In-Reply-to: KMP%SCRC-STONY-BROOK:ARPA's message of Monday, June 9, 1986
12:23 pm
Message-ID: <860619-123848-1153@Xerox>
Char-bits aren't portable because they are a property of the physical
keyboard of the machine, and, most keyboards don't have bits that
correspond to them. ("Most" when enumerating all keyboards, computer
keyboards, keyboards on machines that run lisp, or even accepted
standards (DIN, ANSI) for keyboards.)
The best thing that a "portable" program can do to cope with the variety
of keyboards is twofold:
a) stick as much as possible within the set of standard characters
b) mark the mapping of keys to characters as a clear
implementation-dependent part of programs that have to go beyond the
standard characters.
Char-bits have no more place in the "standard" than does
double-bucky-coke-bottle.
Larry
∂19-Jun-86 1438 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Common LISP meeting at AAAI
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 19 Jun 86 14:37:48 PDT
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a004652; 18 Jun 86 18:18 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Wed, 18 Jun 86 12:32:52 -0100
Message-Id: <8625.8606181132@aiva.ed.ac.uk>
To: BRANDON@ibm.com, Fahlman@c.cs.cmu.edu
Subject: Re: Common LISP meeting at AAAI
Cc: common-lisp@su-ai.arpa
I'm confused. Are we talking about a meeting at AAAI or at the Lisp
conference? I was planning to attend only the former.
∂20-Jun-86 0145 FAHLMAN@C.CS.CMU.EDU Common LISP meeting at AAAI
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jun 86 16:53:48 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 19 Jun 86 19:53:18-EDT
Date: Thu, 19 Jun 1986 19:53 EDT
Message-ID: <FAHLMAN.12216171312.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@CS.UCL.AC.UK>
Cc: common-lisp@SU-AI.ARPA
Subject: Common LISP meeting at AAAI
In-reply-to: Msg of Wed 18 Jun 86 12:32:52 -0100 from Jeff Dalton <jeff%aiva.edinburgh.ac.uk at Cs.Ucl.AC.UK>
There was talk of a Common Lisp meeting at the Lisp Conference. We
don't currently plan to have a general session on Common Lisp at the
Lisp conference, though there will be some assorted Common Lisp
activities happening there, probably including a meeting on
object-oriented facilities.
As far as I know, there has have never been any plans for Common Lisp
activities at the AAAI conference in Philly, except for the usual trade
show. Any indication to the contrary was probably a typo.
-- Scott
∂20-Jun-86 0154 gls@Think.COM out-of-range subsequences
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 19 Jun 86 18:58:38 PDT
Received: from thorlac by Godot.Think.COM via CHAOS; Thu, 19 Jun 86 21:26:12 edt
Date: Thu, 19 Jun 86 21:27 EDT
From: Guy Steele <gls@Think.COM>
Subject: out-of-range subsequences
To: Dave.Touretzky@A.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <8606190724.AA13736@Zarathustra.Think.COM>
Message-Id: <860619212728.1.GLS@THORLAC.THINK.COM>
Date: 18 Jun 86 17:57 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
Watch me ride on both sides of the fence here.
I think (SUBSEQ s x y) should only return an error if x<0 or y<0. I see no
reason to force an expression like (SUBSEQ #(a b c) 0 9) to return an error
when it could return a perfectly useful value instead.
There are lots of cases for lots of functions where one could dream up
a "perfectly useful value" to return in a currently erroneous situation.
For example, inasmuch as (CAR 'NIL) = (CDR 'NIL) = NIL, maybe we should
define (CAR 9) = (CDR 9) = 9. (Or perhaps (CAR 9) = 1 and (CDR 9) = 4.)
If we were to define (SUBSEQ #(a b c) 1 9) to be #(b c), then I don't see
why we should restrict the indices to be non-negative: why not
(SUBSEQ #(a b c) -9 2) = #(a b) as well?
Here are two more arguments against returning an error. First, whether or
not SUBSEQ returns an error, it still has to check the length of the sequence
in order to do the right thing. So if we force the user to write
(SUBSEQ x 0 (min 5 (length x))) the length gets checked twice: once by the
user code, and once by SUBSEQ. This seems wasteful.
Well, SUBSEQ must check the length if it is defined to SIGNAL an error for
an out-of-bound index. If we only require that an out-of-bound index IS an
error, then no check is required in principle (although an implementation
may make such a check in practice).
The second argument is that for lists, there is already precedent for
permitting out of range indexing, e.g. (NTH '(a b c) 7) returns NIL rather
than an error. I don't object to ELT returning an error in this case because
there's no more natural thing to do in the case of vectors. (Consing up an
returning a new empty vector would be a dumb idea.) But in the case of
SUBSEQ there is a perfectly good behavior, namely, return as much of the
sequence as actually exists.
The behavior of NTH is a "natural" consequence of (CAR NIL) = (CDR NIL) = NIL.
The index for NTH must be non-negative, says the spec.
-- Dave
--Guy
∂20-Jun-86 0231 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Argument Lists
Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 19 Jun 86 23:38:31 PDT
Received: from DUANE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 37141; Fri 20-Jun-86 02:39:22-EDT
Date: Fri, 20 Jun 86 02:38 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Argument Lists
To: MILNES%cgi.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: The message from MILNES%cgi.csnet@CSNET-RELAY.ARPA
Message-ID: <860620023813.7.CFRY@DUANE.AI.MIT.EDU>
From: Brian Milnes @cgi.csnet.com
We here at CGI have run into several cases where we would
like to be able to access the argument list format for functions and
macros in a system independent manner. The symbolics and the TI support
a function arglist which returns the lambda list for a function; we
are using this to provide a command like ctr-A, which describes a
functions argument list, in Knowledge Craft.
I also would like a Common Lisp way of determining the minimum
and maximum number of arguments taken by a given function;
ARGLIST gives you info about &optional, &rest and keyword args from which you
can get min and max arg count if you want it.
Have we missed this functionality in CLtL ? Do others of you
out there miss this functionality ? Could it be simply and safely
added to CL ?
I vote for adding arglist, but not minimum-args and maximum-args, though I
have to admit I've had to write that functionality myself.
∂20-Jun-86 0231 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM packages and portability
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 19 Jun 86 23:28:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26471; Fri 20-Jun-86 02:27:13 EDT
Date: Fri, 20 Jun 86 02:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: packages and portability
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8606161358.AA08975@decwrl.DEC.COM>
Message-ID: <860620022603.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I don't have anything to add to this discussion, other than to mention
that what Symbolics does is essentially identical to what Ugo Buy
described in his message of 16 June, except that the default value
for the :USE argument to MAKE-PACKAGE and IN-PACKAGE is as documented
in CLtL. LISP is a nickname on the package named COMMON-LISP. The
package containing our extended version of Common Lisp is named
SYMBOLICS-COMMON-LISP, the same as the name of the language it
implements except in all upper case.
∂20-Jun-86 0305 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Achieving portability, how?
Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 19 Jun 86 23:44:10 PDT
Received: from DUANE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 37142; Fri 20-Jun-86 02:45:00-EDT
Date: Fri, 20 Jun 86 02:43 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Achieving portability, how?
To: Rem@IMSSS, COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 18 Jun 86 12:03-EDT from Rem@IMSSS
Message-ID: <860620024352.8.CFRY@DUANE.AI.MIT.EDU>
There seem to be several ways to achieve portability:
(3) Provide tools for examining the text (source) of a program and reporting
any non-portable syntax. These tools could be used anywhere.
Agreed, no matter what else is decided.
Nice candidate for the yellow pages. It could check each function call to
a valid CL fn that you were passing a correct number of args to it as well.
That would go a long way to catching those calls to CL fns
where an implementation added that addition &optional arg which is
illegal.
∂20-Jun-86 0327 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Achieving portability, how?
Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 19 Jun 86 23:45:50 PDT
Received: from DUANE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 37144; Fri 20-Jun-86 02:46:35-EDT
Date: Fri, 20 Jun 86 02:45 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Achieving portability, how?
To: COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 18 Jun 86 12:03-EDT from Rem@IMSSS
Message-ID: <860620024525.9.CFRY@DUANE.AI.MIT.EDU>
There seem to be several ways to achieve portability:
...
(3) Provide tools for examining the text (source) of a program and reporting
any non-portable syntax. These tools could be used anywhere.
Agreed, no matter what else is decided.
Nice candidate for the yellow pages. It could check each function call to
a valid CL fn that you were passing a correct number of args to it as well.
That would go a long way to catching those calls to CL fns
where an implementation added that addition &optional arg which is
illegal.
∂20-Jun-86 0932 LOOSEMORE@UTAH-20.ARPA require
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 20 Jun 86 09:32:41 PDT
Date: Fri 20 Jun 86 10:31:15-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: require
To: common-lisp@SU-AI.ARPA
Message-ID: <12216352996.24.LOOSEMORE@UTAH-20.ARPA>
Consider the following piece of code:
(in-package 'me)
(require 'foo) ; Module FOO creates package FOO
(foo:some-function)
There is nothing wrong with this when you run it through the interpreter,
but it dies when you try to compile it. Why? Because the call to REQUIRE
doesn't get evaluated at compile time, thus module FOO doesn't get loaded,
package FOO isn't created and SOME-FUNCTION isn't made an external symbol.
The manual has taken some pains to describe how you should order the calls
to set up the package environment and load various modules at the beginning
of each file, but it doesn't seem to interact with the compiler very well.
Making REQUIRE so it is always implicitly (eval-when (eval compile load)...)
would solve the problem, but this would create problems, too. I have at
least one utility where I want one module loaded at compile time to provide
definitions for some rather hairy macros, and another (much smaller) module
around at load time which contains a few functions for runtime support.
I'm inclined to think that this is another manifestation of fundamental
defects in the package system, combined with general vagueness on what
kind of processing goes on at compile time. Unfortunately, I don't really
have any good solutions for either problem. It seems like what we really
need is some mechanism to declare that REQUIRE and various other defining
forms (like DEFSTRUCT, DEFTYPE, DEFMACRO, etc.) should be evaluated at
compile time, *unless* you specify otherwise. Or, maybe a "defenvironment"
construct to take the place of random function calls to set up the package
system and miscellaneous environment.
-Sandra Loosemore
-------
∂20-Jun-86 1210 REM@IMSSS Namestring&pathstring returning shared structure
Received: from IMSSS by SU-AI with PUP; 20-Jun-86 12:10 PDT
Date: 20 Jun 1986 1205-PDT
From: Rem@IMSSS
Subject: Namestring&pathstring returning shared structure
To: COMMON-LISP@SU-AI
It seems to me that the user needs some way to know whether a string is
being shared or not, so he/she can copy it before modifying it if it is
being shared and avoid the extra copy if it has already been copied.
Alternately the CL system should perform copy-on-modify automatically
to avoid the programmer having to make this decision. Thus either make
the manual more precise so it says exactly which functions work in place
and which make copies (this may be too restrictive), or implement some kind
of readonly memory i.e. copy-on-write. Many machines don't have a way to
do this in hardware (trapping on modify, causing LISP to punt and copy first
then try the modify again), but this could be done within the tagged or
paged LISP architecture. In a tagged system such as PSL, simply have two
different tags on string-pointers, one that is normal, and one that is
DON'T EVER MODIFY THIS IN PLACE. The string-modifying operations would
discriminate between these two tags, whereas normal string stuff would just
accept both as strings and pass the tag along when building into structure.
In a paged system such as BIBOP, readonly strings could be on special pages.
Are there any CL implementations which don't use BIBOP nor a tagged
architecture, where there is no obvious method for protecting PNAMEs
against accidental modification in place?
-------
∂20-Jun-86 1224 FAHLMAN@C.CS.CMU.EDU Namestring&pathstring returning shared structure
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jun 86 12:23:59 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 20 Jun 86 15:23:47-EDT
Date: Fri, 20 Jun 1986 15:23 EDT
Message-ID: <FAHLMAN.12216384378.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: COMMON-LISP@SU-AI.ARPA
Subject: Namestring&pathstring returning shared structure
In-reply-to: Msg of 20 Jun 1986 15:05-EDT from Rem at IMSSS
In reply to: Rem at IMSSS
Putting in a copy-on-modify facility is much too radical a change to deal
with this particular problem. We will clarify the document.
-- Scott
∂20-Jun-86 1441 snyder%hplsny@hplabs.HP.COM Re: require
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 20 Jun 86 14:40:32 PDT
Received: from hplsny by hplabs.HP.COM ; Fri, 20 Jun 86 14:39:03 pdt
Received: by hplsny ; Fri, 20 Jun 86 14:38:59 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8606202138.AA03317@hplsny>
Date: Friday, June 20, 1986 14:38:52
Subject: Re: require
To: LOOSEMORE@UTAH-20.ARPA
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 20-Jun-86 10:31:15
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Consider the following piece of code:
(in-package 'me)
(require 'foo) ; Module FOO creates package FOO
(foo:some-function)
There is nothing wrong with this when you run it through the interpreter,
but it dies when you try to compile it. Why? Because the call to REQUIRE
doesn't get evaluated at compile time, thus module FOO doesn't get loaded,
package FOO isn't created and SOME-FUNCTION isn't made an external symbol.
The manual has taken some pains to describe how you should order the calls
to set up the package environment and load various modules at the beginning
of each file, but it doesn't seem to interact with the compiler very well.
Your example demonstrates why REQUIRE should implicitly be evaluated by the
compiler. I believe one can also deduce this fact from the examples in the
chapter on packages (assuming them to be compilable), but it is not stated
explicitly in the definition.
Making REQUIRE so it is always implicitly (eval-when (eval compile load)...)
would solve the problem, but this would create problems, too. I have at
least one utility where I want one module loaded at compile time to provide
definitions for some rather hairy macros, and another (much smaller) module
around at load time which contains a few functions for runtime support.
It would be nice if (EVAL-WHEN (EVAL LOAD) (REQUIRE ...)) did the trick, but
unfortunately EVAL-WHEN has been explicitly defined NOT to be able turn off
implicit compile-time evaluation. I believe that it should do this, and
argued so a long time ago.
Alan
-------
∂20-Jun-86 1930 NGALL@G.BBN.COM defconstant
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 20 Jun 86 19:30:31 PDT
Date: 20 Jun 1986 22:29-EDT
Sender: NGALL@G.BBN.COM
Subject: defconstant
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]20-Jun-86 22:29:37.NGALL>
Consider the following:
File foo contains:
(defconstant const ...)
...
File bar contains:
(defun zap (x)
... (reference const x) ...)
Now suppose that I compile file bar in an environment in which I have
already loaded foo. Thus the compiler will recognize that the
reference to const in zap is a reference of a constant.
In some implementations, the value of const will be substituted for
const. In others, const may be treated like any other special
variable.
But how about an implementation that does the following: It
substitutes a reference to a slot in the compiled function's "constant
vector" (i.e., the piece of data where most implementations store
constant values). BUT it does not init the slot at compile time (like
most implementations), instead, it generates code that will init. the
slot to the value that const has at load time!
Thus, if I loaded bar before loading foo, I will cause an error, since
const is undefined at the time bar is loaded.
My questions are: Is this a legal implemenation of defconstant? If
not, how does CLtL forbid it?
In my opinion, it is not legal CL. I base this on the fact that
defconstant, like defvar and defparameter, defines a variable (albeit
one which about which the compiler may make assumptions). And nowhere
in CLtL does it state that it is an error to load a piece of code that
conatains a reference of a variable that is unbound at load time. CLtL
only requires that the varibable have a value at the moment the
reference is evaluated.
The only argument in favor of considering such behavior legal would be
based on the statement "defconstant ... [asserts] that the value of
the variable NAME is fixed" One could argue that the value of the
variable at compile time was different from the value at load time
(i.e., the value UNBOUND), and thus the assertion has been
contradicted.
What do you think? By the way, thre does exist such an
implementation: KCL.
-- Nick
∂20-Jun-86 2004 FAHLMAN@C.CS.CMU.EDU defconstant
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jun 86 20:04:16 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 20 Jun 86 23:03:40-EDT
Date: Fri, 20 Jun 1986 23:03 EDT
Message-ID: <FAHLMAN.12216468116.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: defconstant
In-reply-to: Msg of 20 Jun 1986 22:29-EDT from NGALL at G.BBN.COM
I agree with Nick's analysis. A reference to a constant may be compiled
as a variable reference or the value of the constant at compile time may
be wired into the code, but if the latter is done, this should not
depend on the constant having been initialized at load time. I agree
that the manual is too vague on this point, and should be clarified.
I suspect that KCL handles Defconstant this way in order to optimize the
use of lists as constants, while still observing the requirement that
all references to the constant must be EQL to one another, but this is a
very tricky business and is probably not worth the trouble it takes to
get it right.
-- Scott
∂20-Jun-86 2126 mips!pachyderm.earl@su-glacier.arpa require
Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 20 Jun 86 21:26:15 PDT
Received: by su-glacier.arpa with Sendmail; Fri, 20 Jun 86 21:26:08 pdt
Received: from pachyderm.UUCP (pachyderm.ARPA) by mips.UUCP (4.12/4.7)
id AA11371; Fri, 20 Jun 86 18:25:31 pdt
Received: by pachyderm.UUCP (4.12/4.7)
id AA12833; Fri, 20 Jun 86 18:15:25 pdt
Date: Fri, 20 Jun 86 18:15:25 pdt
From: mips!pachyderm.earl@su-glacier.arpa (Earl Killian)
Message-Id: <8606210115.AA12833@pachyderm.UUCP>
To: glacier!LOOSEMORE@UTAH-20.ARPA
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: SANDRA's message of Fri 20 Jun 86 10:31:15-MDT
Subject: require
I certainly hope that REQUIRE does something at compile time. The
whole purpose of REQUIRE was to make exactly this sort of thing
painless.
∂20-Jun-86 2153 Larry←Masinter.PARC@Xerox.COM Re: Namestring&pathstring returning shared structure
Received: from XEROX.COM by SU-AI.ARPA with TCP; 20 Jun 86 21:53:00 PDT
Received: from Burger.ms by ArpaGateway.ms ; 20 JUN 86 21:53:01 PDT
Sender: "Larry←Masinter.PARC"@Xerox.COM
Date: 20 Jun 86 21:52:46 PDT (Friday)
Subject: Re: Namestring&pathstring returning shared structure
From: masinter.PARC@Xerox.COM
To: Rem@IMSSS.Arpa
cc: COMMON-LISP@SU-AI.Arpa
In-Reply-to: Rem%IMSSS:ARPA's message of Friday, June 20, 1986 1:41 pm
Reply-to: masinter.PARC@Xerox.COM
Message-ID: <860620-215301-1126@Xerox>
From as early as 1972, Interlisp in all implementations performed "copy
on write for substrings of pnames". This required neither BIBOP or page
tables or tag bits.
This is one "is an error" condition that is fairly painful: it isn't
determinable by even the most careful amount of flow analysis, much less
a simple syntactic check.
To change "it is an error to destructively modify the pname of a
symbol", it is necessary to either introduce copy-on-write or else
change it to "signals an error". If the former is controversial, would
you accept the latter?
∂21-Jun-86 0033 OKUNO@SUMEX-AIM.ARPA negative index for the sequence
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 21 Jun 86 00:29:44 PDT
Date: Sat 21 Jun 86 00:27:34-PDT
From: Hiroshi G. Okuno <Okuno@SUMEX-AIM.ARPA>
Subject: negative index for the sequence
To: gls@ZARATHUSTRA.THINK.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860619212728.1.GLS@THORLAC.THINK.COM>
Message-ID: <12216516165.13.OKUNO@SUMEX-AIM.ARPA>
> Well, SUBSEQ must check the length if it is defined to SIGNAL an error for
> an out-of-bound index.
>
> --Guy
If the length check is performed in SUBSEQ, a negative index may be
considered as a convention of
-n == (- (length <object>) n) where n > 0.
For example,
(subseq #(a b c d e) -3 -1) = (subseq #(a b c d e) 2 4) = #(c d e)
Of course, if the non-negative index which corresponds to a negative one
exceeds the bound of the sequence, an error is signalled.
This convention is very useful for string manipulations. In fact,
a negative index is supported in TAO and used extensively in a
kana-kanji conversion programs.
- Gitchang -
-------
∂21-Jun-86 0108 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Common LISP meeting at Lisp Conference
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 21 Jun 86 01:07:33 PDT
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a000440; 20 Jun 86 18:35 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Fri, 20 Jun 86 18:33:54 -0100
Message-Id: <3983.8606201733@aiva.ed.ac.uk>
To: Fahlman@c.cs.cmu.edu, jeff <@Cs.Ucl.AC.UK:jeff@aiva.edinburgh.ac.uk>
Subject: Re: Common LISP meeting at Lisp Conference
Cc: common-lisp@su-ai.arpa
Date: Thu, 19 Jun 1986 19:53 EDT
From: "Scott E. Fahlman" <Fahlman@edu.cmu.cs.c>
There was talk of a Common Lisp meeting at the Lisp Conference. We
don't currently plan to have a general session on Common Lisp at the
Lisp conference, though there will be some assorted Common Lisp
activities happening there, probably including a meeting on
object-oriented facilities.
Good. I would also like to mention that the August EuLisp meeting is going
to take place in Boston during the conference:
Date: Tue, 17 Jun 86 11:17:12 bst
From: jap <jap@uucp.m42>
To: eulisp@uucp.inria
I sent off a message to Bert Halstead (cc'ed to Bob Mathis) about trying
to arrange a room for a meeting for those interested in LISP
standardisation. That was passed to Richard Gabriel, who contacted me
yesterday. He is keen that there should be some meeting where our
working group and the assorted CL folks can get together. I have
suggested the Tuesday evening as being the best time.
I think it's important that the different groups interested in standard-
ization have a chance to talk directly, especially since the overlap
between the two mailing lists is not that great.
-- Jeff
∂21-Jun-86 0941 FAHLMAN@C.CS.CMU.EDU Namestring&pathstring returning shared structure
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Jun 86 09:41:33 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 21 Jun 86 12:41:36-EDT
Date: Sat, 21 Jun 1986 12:41 EDT
Message-ID: <FAHLMAN.12216617014.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: masinter.PARC@XEROX.COM
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Namestring&pathstring returning shared structure
Signaling an error or doing a copy when someone destructively modifies
the string for a symbol's name is a pain. If there's a problem here, we
should simply make sure the user never gets his hands on such a string
by copying on the way in and copying again on the way out. However, I'm
not convinced that there's a problem here, except that the manual does
not state clearly enough that this string is shared, registered in a
hash table, and should not be messed with. Are people really in danger
of screwing themselves here?
-- Scott
∂21-Jun-86 0942 OKUNO@SUMEX-AIM.ARPA negative index for the sequence (correction)
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 21 Jun 86 09:42:23 PDT
Date: Sat 21 Jun 86 09:36:00-PDT
From: Hiroshi G. Okuno <Okuno@SUMEX-AIM.ARPA>
Subject: negative index for the sequence (correction)
To: Okuno@SUMEX-AIM.ARPA, gls@ZARATHUSTRA.THINK.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12216516165.13.OKUNO@SUMEX-AIM.ARPA>
Message-ID: <12216616005.17.OKUNO@SUMEX-AIM.ARPA>
My original message contains a bug. The sentence
> Of course, if the non-negative index which corresponds to a negative one
> exceeds the bound of the sequence, an error is signalled.
should read
If (abs <index>) is out-of-range, an error is signalled.
Thanks,
- Gitchang -
-------
∂21-Jun-86 1337 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: Why aren't char bits portable?
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 21 Jun 86 13:36:17 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26595; Fri 20-Jun-86 10:34:25 EDT
Date: Fri, 20 Jun 86 10:37 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Why aren't char bits portable?
To: Masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860619-123848-1153@Xerox>
Message-ID: <860620103733.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
I agree with everything you say in your message, except that I would
modify the conclusion somewhat. I believe that the intent of including
"bits" in the standard is to allow for the fact that some of the "bits"
are gaining some amount of currency as ad hoc standards. In particular,
there are now several terminals on the market that have a "Meta" key,
which is used by many Emacs-family editors. (The Ann Arbor Ambassador
and the Teleray something (2000?) come to mind.)
A program that wants to be universally portable, of course, cannot
depend on the presence of such key on the user's keyboard. However, it
is not hard to imagine a program that wants to be portable, but also
wants to allow any user who has a Meta key to take advantage of it.
(Indeed, many Emacs-family editors have this property.)
I believe the intention of the "bits" feature was to help out such
programs. While I'm not sure that all the details of the "bits" feature
in the standard are ideal, nevertheless I wanted to point out that the
entire feature is not necessarily bankrupt.
∂21-Jun-86 1800 FAHLMAN@C.CS.CMU.EDU negative index for the sequence
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Jun 86 17:53:15 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 21 Jun 86 20:53:12-EDT
Date: Sat, 21 Jun 1986 20:53 EDT
Message-ID: <FAHLMAN.12216706501.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Hiroshi G. Okuno" <Okuno@SUMEX-AIM.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: negative index for the sequence
In-reply-to: Msg of 21 Jun 1986 03:27-EDT from Hiroshi G. Okuno <Okuno at SUMEX-AIM.ARPA>
I find the use of negative indices to mean "count backward from the end
of the sequence" is very confusing, especially in the Common Lisp
sequence functions, may of which already have a :FROM-END option and
other complexities. This wouldn't be so bad in SUBSEQ alone, but then
it would make that function different from all the others in how it
handles indices. Maybe this convention works well in TAO, but I don't
think it would work well in Common Lisp.
-- Scott
∂21-Jun-86 1955 FAHLMAN@C.CS.CMU.EDU Argument Lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Jun 86 19:55:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 21 Jun 86 22:54:48-EDT
Date: Sat, 21 Jun 1986 22:54 EDT
Message-ID: <FAHLMAN.12216728644.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MILNES%cgi.csnet@CSNET-RELAY.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Argument Lists
In-reply-to: Msg of Wed 18 Jun 86 19:17 ??? from MILNES%cgi.csnet at CSNET-RELAY.ARPA
In response to your request for a portable Common Lisp facility to
access any function's argument list and also its minimum and maximum arg
counts:
I think that the overwhelming majority of implementations provide some
sort of function for accessing the argument list. The names that the
user gave to the arguments can be a very useful form of automatic
documentation, so this info is just too valuable not to make available
in some form at runtime. I'm sure that if we took a poll, however, we
would find many different formats in use for reporting this information.
For example, do we return the original arglist, with all of the
default-argument forms in place, or just the variable names and which
ones are optional, rest, etc.
I think that it would be valuable to agree on the format for reporting
the arglist and include it in the language as a standard or
semi-standard facility so that we can all use it in the same way on
various machines and so that code can make use of this. (Various help
systems would make good use of this info.) We might want to make this a
"semi-standard" feature, meaning that it is optional, but do it this way
if you do it at all, since very small implementations might not want to
pay the price to keep this info around at runtime. Then again, we added
docuemntation strings as a required facility and nobody complained --
these are kept outside the Lisp in a separate file in some
implementations, and the arglist info could be kept there as well.
Every implementation has some way of determining at runtime the minimum
and maximum argument counts for a function, so functions to report these
could be added at very little cost. These, too, would be useful, though
you could derive this from the arglist info if you had to.
-- Scott
∂21-Jun-86 2000 NGALL@G.BBN.COM Re: Namestring&pathstring returning shared structure
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 21 Jun 86 20:00:30 PDT
Date: 21 Jun 1986 22:59-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Namestring&pathstring returning shared structure
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: masinter.PARC@XEROX.COM, COMMON-LISP@SU-AI.ARPA
Message-ID: <[G.BBN.COM]21-Jun-86 22:59:24.NGALL>
In-Reply-To: <FAHLMAN.12216617014.BABYL@C.CS.CMU.EDU>
Date: Sat, 21 Jun 1986 12:41 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: masinter.PARC@XEROX.COM
Subject: Namestring&pathstring returning shared structure
Message-ID: <FAHLMAN.12216617014.BABYL@C.CS.CMU.EDU>
Signaling an error or doing a copy when someone destructively modifies
the string for a symbol's name is a pain. If there's a problem here, we
should simply make sure the user never gets his hands on such a string
by copying on the way in and copying again on the way out. However, I'm
not convinced that there's a problem here, except that the manual does
not state clearly enough that this string is shared, registered in a
hash table, and should not be messed with. Are people really in danger
of screwing themselves here?
-- Scott
--------------------
I agree that all that is needed is more clarity in the manual as to
which functions are guaranteed to return unshared structures, which
functions return shared structures, and which functions for which the
sharability of the object returned is undefined.
I think I may have misled people into thinking that I was only worried
about the interaction of pathnames and symbol-names. I was just using
it as an example on implicit sharing (one that caused me a lot of
grief in porting to KCL). But there are many other examples of
possible character sharing between strings (e.g., string-trim,
parse-namestring, package-name, intern, etc.). Implementations such
as KCL, which use separate string headers and bodies (which are just
raw sequences of chars.) will typically just create a new string
header which points into an existing string body whenever possible.
Unless the user knows when to be on the alert for this, s/he will
eventually come to grief.
-- Nick
∂22-Jun-86 1431 snyder%hplsny@hplabs.HP.COM Re: Namestring&pathstring returning shared structure
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 22 Jun 86 14:31:43 PDT
Received: from hplsny by hplabs.HP.COM ; Sun, 22 Jun 86 14:30:45 pdt
Received: by hplsny ; Sun, 22 Jun 86 14:30:39 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8606222130.AA03808@hplsny>
Date: Sunday, June 22, 1986 14:30:31
Subject: Re: Namestring&pathstring returning shared structure
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 21-Jun-86 12:41:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
CLU solved this problem by making STRING a different type than ARRAY of
CHARACTER, and by making STRINGs immutable. We found having immutable STRINGs
to be extremely useful: one can pass a string to a procedure or return it from
a procedure without worrying that someone might destructively modify it! This
idea was such a win that a later revision of CLU had both immutable and
mutable arrays and immutable and mutable records.
Something to think about for Common Lisp 2000...
Alan
-------
∂22-Jun-86 1843 FAHLMAN@C.CS.CMU.EDU portability of pathnames
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Jun 86 17:30:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Jun 86 20:30:13-EDT
Date: Sun, 22 Jun 1986 20:30 EDT
Message-ID: <FAHLMAN.12216964464.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: portability of pathnames
In-reply-to: Msg of 29 May 1986 22:20-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
I'm going through old mail to make a list of issues we need to settle,
or at least work on. I came across your complaint about portability of
pathnames and the problems with make-pathname. I was just wondering if
you had anything specific to propose. If not, I'll just add this to the
agenda of things we collectively need to think about, but I'm not sure
there's a good solution to be had.
-- Scott
∂22-Jun-86 1843 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument Lists
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jun 86 18:43:44 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 27337; Sun 22-Jun-86 02:55:46 EDT
Date: Sun, 22 Jun 86 02:52 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Argument Lists
To: Fahlman@C.CS.CMU.EDU
cc: KMP@SCRC-STONY-BROOK.ARPA, COMMON-LISP@SU-AI.ARPA
References: <FAHLMAN.12216728644.BABYL@C.CS.CMU.EDU>
Message-ID: <860622025257.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
About 20% of the 10000 symbols in MACSYMA have have no function cell, value,
or properties. The average length of those symbols' names is 7.33. Some are
probably used as constants within programs, including plist indicators and
catch tags, but I can't believe that all of them are. I'm more inclined to
believe that most of these are arguments to functions and other variables
(eg, for LET, PROG, etc) which are being retained for debugging. Sometime
when I have more time, maybe I'll try to track down more details.
Symbolics have no real problem with retaining such information on the 3600,
but I'm not sure what the cost/benefit trade-off is of requiring that this
information be retained in implementations that are tighter on address space.
Also, I should mention that MACSYMA wants to be able to detect the maximum
and minimum number of arguments a function takes, but doesn't really have
a lot of important uses for the whole argument list. The only real argument
I can think of for anyone wanting the actual argument list is as a
user-interface/self-documentation feature, which is an issue that may be best
left up to individual systems. I expect that some people will disagree with
this, though.
Personally, I think that ARGLIST is something of an abstraction violation when
used in some of the ways that I've seen it used, because it exposes the names
the user was using internally and in some cases that may reveal artifacts of
the implementation which ought not be revealed for reasons either of
abstraction or proprietariness or both. Of course, APROPOS is in the same
boat, so I won't suggest there's no precedent for such operations in CL.
There's also a question of how fast ARGLIST wants to be. Some implementations
may have to cons this back up, but some users may be wanting something that's
fast enough to use as a check before actually trying to apply a function in
order to head off wrong-number-of-arguments errors before they happen. The
latter application may not be happy with the speed required to cons an
arglist. Having more than one function to get these two things would seem
better than having one sledge-hammer that always computes twice as much info
as it needs to and then makes you throw half of that information away.
Storing ARGLIST information out of core would reduce the size requirement, but
would likely make it unacceptably slow for any kind of number-of-args
checking. Also, unlike documentation strings which you can simply drop the
pointers to when you're done using them, symbols that were in the arglist read
from an out-of-core file would continue to be interned unless you explicitly
uninterned them, and you can't do that very safely unless you know for sure
the symbol hadn't been interned prior to the call to ARGLIST. So over time,
you'd end up accumulating all the information in core in a non-GC-able way.
Maybe that would be OK, but it's worth thinking carefully about to be sure.
Personally, I think something that computes minimum/maximum number of
arguments should be put into the language. I'll defer any recommendation about
something which gets the ARGLIST itself until I've thought harder about the
implications.
If ARGLIST is put in, it should probably be under the name ARGUMENT-LIST.
∂22-Jun-86 1909 DT50@A.CS.CMU.EDU Re: Argument Lists
Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Jun 86 19:03:27 PDT
Date: 22 Jun 86 22:01 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
To: common-lisp@SU-AI.ARPA
Subject: Re: Argument Lists
In-Reply-To: <860622025257.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
One compromise might be to include ARGUMENT-LIST in the language but specify
that the argument lists of compiled functions may not be accessible. So
people writing programmer's aids for handling interpreted code (as I have
done) can still get the info they want without being forced to rip apart
closure objects or SI:DIGESTED-LAMBDA forms. There should probably be a
compiler declaration to force argument list info to be preserved (or thrown
away), for applications like Brian Milnes' where you need the info in
compiled code. The default fate of argument lists in compiled functions can
be left up to the implementation.
We should not compromise on number of args info though; that should be
available for all functions, compiled or not.
By the way, what will the convention be for indicating that a function has
an &rest arg? I guess one could just return the value of call-arguments-limit.
-- Dave
∂23-Jun-86 0706 DCP@RIVERSIDE.SCRC.Symbolics.COM Re: Namestring&pathstring returning shared structure
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 07:06:28 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 27642; Mon 23-Jun-86 10:05:35 EDT
Date: Mon, 23 Jun 86 10:03 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Namestring&pathstring returning shared structure
To: Alan Snyder <snyder%hplsny@hplabs.HP.COM>, Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8606222130.AA03808@hplsny>
Message-ID: <860623100356.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sunday, June 22, 1986 14:30:31
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
CLU solved this problem by making STRING a different type than ARRAY of
CHARACTER, and by making STRINGs immutable. We found having immutable STRINGs
to be extremely useful: one can pass a string to a procedure or return it from
a procedure without worrying that someone might destructively modify it! This
idea was such a win that a later revision of CLU had both immutable and
mutable arrays and immutable and mutable records.
It must be a bitch to write an editor in CLU, or do you just implement
lines as arrays of characters instead of as strings, thereby losing the
textual benefit of debugging and having to write separate output
routines to display these "strings"?
Something to think about for Common Lisp 2000...
∂23-Jun-86 0813 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Re: Argument Lists
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 08:13:06 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3026; 23 Jun 86 11:13:51-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 25300; Mon 23-Jun-86 11:13:34-EDT
Date: Mon, 23 Jun 86 11:12 EST
Sender: mike@a
To: Dave.Touretzky@A.CS.CMU.EDU
From: mike%gold-hill-acorn@mit-live-oak.arpa "Mike Beckerle"
Subject: Re: Argument Lists
Cc: common-lisp@SU-AI.ARPA
Date: 22 Jun 86 22:01 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
One compromise might be to include ARGUMENT-LIST in the language but specify
that the argument lists of compiled functions may not be accessible. So
people writing programmer's aids for handling interpreted code (as I have
done) can still get the info they want without being forced to rip apart
closure objects or SI:DIGESTED-LAMBDA forms. There should probably be a
compiler declaration to force argument list info to be preserved (or thrown
away), for applications like Brian Milnes' where you need the info in
compiled code. The default fate of argument lists in compiled functions can
be left up to the implementation.
We should not compromise on number of args info though; that should be
available for all functions, compiled or not.
By the way, what will the convention be for indicating that a function has
an &rest arg? I guess one could just return the value of call-arguments-limit.
-- Dave
Asking for the number of args at run time, or whether the function
takes an &rest arg is asking for type information about functions.
Someone else might want to know the number of results, or possibly
the types of the arguments, etc. Common Lisp already has typing
features which address these kinds of problems. For example, the
type-of operation can be used for this purpose, i.e., why not do:
(type-of (symbol-function 'foo))
and have it return the function type specifier, which might be:
(function (t t &optional t &rest list) t)
This could then be parsed to determine the number of args info, or
any other available type info about the function. Requiring that
number-of-args be available is tantamount to requiring type-of to
always be able to return a function signature containing at least the
right number of arguments. In other words, it is equivalent to
asking that the type-of function be required to return alot more
information than CLtL currently specifies.
I think type-of should be required to return a function type
specifier for function objects, and that the lambda list in the
specifier must reflect the arity, as well as use of &key, &optional,
&rest, etc. Argument-list should then be defined in terms of type-of.
Note that since type-of returns a function type specifier instead
of an actual lambda-list, there is no loss of abstraction here, i.e.,
only the type of each argument is shown, not the name of it.
This may be a bug, since at the user-interface level, most use
of arglist is to look at the names of the args to determine
their order, not their type. Extending the function spec syntax
is one way to fix this, i.e.,
(function ((the integer x) &optional ((the list foo) nil)) t)
Also, number-of-args is quite ambiguous in the presence of &key,
&optional, and &rest args, and would be especially troublesome
with respect to macros, where nested lambda lists can be used.
...mike beckerle
Gold Hill Computers
∂23-Jun-86 0814 NGALL@G.BBN.COM Re: portability of pathnames
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 08:13:46 PDT
Date: 23 Jun 1986 11:11-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: portability of pathnames
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]23-Jun-86 11:11:44.NGALL>
In-Reply-To: <FAHLMAN.12216964464.BABYL@C.CS.CMU.EDU>
Date: Sun, 22 Jun 1986 20:30 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: portability of pathnames
In-Reply-To: Msg of 29 May 1986 22:20-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
Message-ID: <FAHLMAN.12216964464.BABYL@C.CS.CMU.EDU>
I'm going through old mail to make a list of issues we need to settle,
or at least work on. I came across your complaint about portability of
pathnames and the problems with make-pathname. I was just wondering if
you had anything specific to propose. If not, I'll just add this to the
agenda of things we collectively need to think about, but I'm not sure
there's a good solution to be had.
-- Scott
--------------------
I don't remeber what Sandra's suggestion was, but I have one:
On page 409 of CLtL it says, "names can be fit into a certain
canonical, implementation-independent form called a pathname."
But on page 412 it says, "What values are allowed for components of a
pathname depends, in genneral, on the pathname's host." Given this
latter statement, it seems that the only implementation-independent
thing about the form of a pathname is that it has 6 components! (Even
this isn't totally true, since some implementations that don't support
versions may not allow assignment of anything to the version component!)
CLtL does state that there are conventions for the components. What I
would like is for these conventions to be required. For example, in
every implementation, one may give MAKE-PATHNAME a :type argument that
is either a string (and CLtL should specify that there are no pathname
specific restrictions on the length of the string) of NIL or :WILD
(such is currently the TYPE convention).
The host convention also makes sense. When I say that all
implementations must accept a string of any length or, in the case of
a host, accept a list of strings, I do not mean that such a pathname
must be convertable into a legal namestring. I merely mean that an
application should should be able to generate pathnames as it sees fit
and delay the 'legality' check until it actually wants to interface to
the file system.
For example, my application uses names that are <= 10 chars. If I
move to a CL that supports names only <= 8 chars, I have to go through
a lot of work to port. But if I can stuff the longer names into a
pathname legally, then a can merely wrap my file-system interface
(e.g., a call to open) with code that would convert my pathname into a
pathname that this system could handle (e.g., by using some of thje
chars avail for the TYPE).
The point I am trying to make is that pathnames really should be 100%
implementation independent, including the contents of each of the
components. There should be no limitations on the components (e.g.,
length of strings, length of lists, whether a list is allowed in this
impl.) other than the conventions on pg. 412. It is the conversion of
a pathname to a namestring (and vice versa) that should impose the
limitations. And the standard should state that all pathnames are
implicity converted to host-dependent namestings before actually being
used in a file-system operation.
The one significant change to the pathname conventions will have to be
to the wording in the description of the conventions of the device,
directory, and name: "...can each be a string (with host dependent
rules on allowed characters and length) or possibly some other Common
Lisp data structure)..." This would have to be changed to remove the
wording about "host dependent rules" (remember, these rules should
only come into play when converting to a namestring) and to flush the
legality of "some other CL data structure". Whats wrong with just
allowing strings, lists of strings, :wild, and nil? Does nayone use
anything else already? Would it be that hard to switch to lists?
Finally, it should be stated that what you assign to a pathname
component is what you get back when you reference it, no implicit
conversion or copying.
This pretty much turns pathnames into merely organizers of
information, they don't process what is assigned to them, they just
store it. It is the process of converting to a namestring that
processes the info, based on implementation independent info.
-- Nick
∂23-Jun-86 0935 NGALL@G.BBN.COM Re: Argument Lists
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 09:34:48 PDT
Date: 23 Jun 1986 12:31-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Argument Lists
From: NGALL@G.BBN.COM
To: KMP@SCRC-STONY-BROOK.ARPA
Cc: Fahlman@C.CS.CMU.EDU, COMMON-LISP@SU-AI.ARPA
Message-ID: <[G.BBN.COM]23-Jun-86 12:31:52.NGALL>
In-Reply-To: <860622025257.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sun, 22 Jun 86 02:52 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
To: Fahlman@C.CS.CMU.EDU
Subject: Argument Lists
Message-ID: <860622025257.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
...
Personally, I think something that computes minimum/maximum number of
arguments should be put into the language. I'll defer any recommendation about
something which gets the ARGLIST itself until I've thought harder about the
implications.
If ARGLIST is put in, it should probably be under the name ARGUMENT-LIST.
--------------------
One tool that would greatly benefit from information about the
lambda-list (the correct Lisp name for a parameter list or [sic]
argument list) is a portable "advise" tool (ala InterLisp and
ZetaLisp). Without information as to the number of required,
optional, and (in some implementations?) keyword arguments (and in the
case of keyword arguments, the names of the keywords), the
encapsulation function will be forced to do unnecessary consing
(because it will have to use &rest) and use a less efficient form of
function calling (in most impl.), APPLY.
The minimum acceptable functionality for a function providing
lambda-list info (I'll call it LAMBDA-LIST) would be the for it to
return the number of required args, the number of requireds+optionals
(or just the number of optional, if you prefer), and a flag indicating
whether or not a &rest/&key is present.
I would prefer that the function return the number of required args,
the number of optional args, a list of keyword names, a flag
indicating whether an &rest parameter exists, and a flag indicating
whether or not an &allow-other-keys exists. But I realize that the
keyword info. may be a bit of a burden on some implementations.
The truly right way to do it is, as Mike Beckerle suggested, return the
type spec (but I wouldn't include the parameter names). But I doubt
that implementors want to invest that much effort in it.
-- Nick
∂23-Jun-86 1128 @MC.LCS.MIT.EDU:uucp@CCC.MIT.EDU
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 Jun 86 11:28:46 PDT
Received: from CCC.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 JUN 86 14:30:37 EDT
Date: 23 Jun 1986 14:27:21-EDT
From: uucp@MIT-CCC
From gjc%mc.ARPA Mon Jun 23 13:42:13 1986 remote from lmi-angel
Received: from LMI-MOE by lmi-angel.ARPA (4.12/4.7) with CHAOS id AA00822; Mon, 23 Jun 86 13:40:31 edt
Date: Monday, 23 June 1986, 13:40-EDT
From: lmi-angel!gjc%mc.ARPA
Subject: Namestring&pathstring returning shared structure
To: mitccc!DCP%QUABBIN.SCRC.Symbolics.COM%mc@angel.ARPA
Cc: mitccc!common-lisp%SU-AI%mc@angel.ARPA
Message-Id: <[LMI-MOE].23-Jun-86 13:40:18.GJC>
Why stop at strings Dave? Another win would be immutable list
structure. Think of it, (as the CLU'ist remarked) you can pass a whole
list to a function without having to worry about the possible RPLACA or RPLACD
operations it may do!
Actually, one could make this into a serious suggestion. Certainly most systems
have so-called pure areas, for example, in the LMI system you get a
write-into-read-only-memory error if you do (setf (aref (get-pname 'foo) 0) #\X),
and perhaps this feature could actually be presented in a system-independant way.
Something along the lines of "if the pure-structure feature is provided then
the primitives should be called PURE-COPY (or PURCOPY) and PURE-P."
-gjc
∂23-Jun-86 1305 FAHLMAN@C.CS.CMU.EDU Common Lisp 2000
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jun 86 13:04:50 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Jun 86 16:04:32-EDT
Date: Mon, 23 Jun 1986 16:04 EDT
Message-ID: <FAHLMAN.12217178236.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jeff Dalton <enea!aiva.ed.ac.uk!jeff@SEISMO.CSS.GOV>
Cc: common-lisp@SU-AI.ARPA
Subject: Common Lisp 2000
How do people feel about making changes like immutable/mutable whatevers
part of the ANSI/ISO standard instead of waiting for Common Lisp 2000?
I don't mean this particular change, which after all we might decide we
don't want at all, but rather changes of this magnitude. The EuLisp
proposals for the ISO standard do contain suggestions on this scale.
I sent out a message a couple of weeks ago describing my own views on
what guidelines we should follow in developing a proposed ANSI/ISO
standard definition for Common Lisp. Basically, the view was that
Common Lisp is already a de facto standard with many implementaitons and
many users. Any tinkering we do on the way to making it an official
standard has to consider the costs of each change, in terms of existing
implementations, application code, user skills, and documents, as well
as any benefits the change might bring. I believe that the guidelines I
suggested accurately reflect the views of the overwhelming majority of
the Common Lisp community (there was only one dissenting message), and
unless that view is shown to be in error, I expect that the new Common
Lisp definition we are developing will follow them.
With Common Lisp we have achieved an important goal: unifying the
commercial part of the Lisp community behind a single dialect.
Developing an official standard for Common Lisp will help to cement that
goal, and will give the commercial world something stable and usable to
hang on to while work continues on better Lisps for the future.
All of us would like to see better, cleaner Lisp systems in use
eventually, and I applaud the efforts of the Eulisp people to develop a
more rational dialect of Lisp and to explore the potential for formal
methods in defining a system of this size. I see no conflict between
this work going forward and the adoption of a standard for Common Lisp.
In fact, if the competitive aspect were eliminated, I think that it
would be much easier for the EuLisp group to stick to their vision of
truth and beauty: no need to make the sorts of compromises that would be
required to win over companies in the short run. In addition, it would
make it easier for us to contribute ideas to the EuLisp development, and
for the EuLisp people to participate in our attempts to clarify Common
Lisp in minor ways.
The stumbling block, as I see it, is the insistence by some of the
Eulisp people that there must be only one Lisp standard in the
forseeable future, and that that place must be reserved for an
"acceptable" dialect, and not the one that everyone is using. The
commercial AI world has just, at great expense, settled on Common Lisp,
and they are not going to make any more radical changes in the next
couple of years, regardless of what we or EuLisp or ISO might do. In a
couple of years (sooner than the year 2000, I think), the industry might
be ready to shift to EuLisp or some version of Scheme or a version of
Common Lisp that is cleaned up in more radical ways. I'd like to see
that happen, when the time is right and when the new candidate has
established itself on its merits. It will happen sooner if we can give
the people in industry a period of relative stability by adopting Common
Lisp as a standard in the meantime.
-- Scott
∂23-Jun-86 1644 Pavel.pa@Xerox.COM Re: Namestring&pathstring returning shared structure
Received: from XEROX.COM by SU-AI.ARPA with TCP; 23 Jun 86 16:44:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUN 86 16:40:49 PDT
Date: 23 Jun 86 16:40 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Namestring&pathstring returning shared structure
In-reply-to: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>'s message
of Mon, 23 Jun 86 10:03 EDT
To: DCP@QUABBIN.SCRC.Symbolics.COM
cc: snyder%hplsny@hplabs.HP.COM, Fahlman@C.CS.CMU.EDU,
common-lisp@SU-AI.ARPA
Message-ID: <860623-164049-2116@Xerox>
Date: Mon, 23 Jun 86 10:03 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
It must be a bitch to write an editor in CLU, or do you just implement
lines as arrays of characters instead of as strings, thereby losing the
textual benefit of debugging and having to write separate output
routines to display these "strings"?
The Cedar system at PARC provides an immutable string type called ROPE's
(thick strings) and the editor in fact uses them. Once you know that
the strings are immutable, you can play all sorts of fun games with
their representation, including sharing structure all over the place and
getting (nearly) constant-time concatenation and substring operations
with very slightly degraded fetch performance. Immutable strings are an
extremely big win and I hope to have us (Xerox) implement them for our
Lisp in the relatively near future.
Pavel
∂23-Jun-86 1655 Pavel.pa@Xerox.COM Re: Argument Lists
Received: from XEROX.COM by SU-AI.ARPA with TCP; 23 Jun 86 16:55:45 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUN 86 16:53:14 PDT
Date: 23 Jun 86 16:51 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Argument Lists
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sat,
21 Jun 86 22:54 EDT
To: Fahlman@C.CS.CMU.EDU
cc: MILNES%cgi.CSNet@CSNet-Relay.ARPA, common-lisp@SU-AI.ARPA
Message-ID: <860623-165314-2126@Xerox>
Date: Sat, 21 Jun 86 22:54 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Every implementation has some way of determining at runtime the minimum
and maximum argument counts for a function, so functions to report
these
could be added at very little cost.
Where in CLtL does it say this? It is not required that an
implementation signal an error when there are either too many or too few
arguments, so I can't see why this information must be available in
every implementation. I don't disagree with the position that it would
be very useful, but it isn't (yet) required.
Pavel
∂23-Jun-86 1716 jhl%hpljl@hplabs.HP.COM common lisp mailing list
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 23 Jun 86 17:15:41 PDT
Received: from hpljl by hplabs.HP.COM ; Mon, 23 Jun 86 17:14:12 pdt
Received: by hpljl ; Mon, 23 Jun 86 17:15:49 pdt
Date: Mon, 23 Jun 86 17:15:49 pdt
From: Joachim H. Laubsch <jhl%hpljl@hplabs.HP.COM>
Message-Id: <8606240015.AA06020@hpljl>
To: common-lisp@su-ai.ARPA
Subject: common lisp mailing list
Could You put me on this mailing list?
Joachim Laubsch
HPLabs
∂23-Jun-86 1810 snyder%hplsny@hplabs.HP.COM Re: Namestring&pathstring returning shared structure
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 23 Jun 86 18:10:11 PDT
Received: from hplsny by hplabs.HP.COM ; Mon, 23 Jun 86 18:08:51 pdt
Received: by hplsny ; Mon, 23 Jun 86 18:08:35 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8606240108.AA02427@hplsny>
Date: Monday, June 23, 1986 18:08:27
Subject: Re: Namestring&pathstring returning shared structure
To: DCP@QUABBIN.SCRC.Symbolics.COM
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 23-Jun-86 10:03:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
CLU solved this problem by making STRING a different type than ARRAY of
CHARACTER, and by making STRINGs immutable. We found having immutable STRINGs
to be extremely useful: one can pass a string to a procedure or return it from
a procedure without worrying that someone might destructively modify it! This
idea was such a win that a later revision of CLU had both immutable and
mutable arrays and immutable and mutable records.
It must be a bitch to write an editor in CLU, or do you just implement
lines as arrays of characters instead of as strings, thereby losing the
textual benefit of debugging and having to write separate output
routines to display these "strings"?
Actually, the Ted editor (written in CLU) did use strings to represent lines
of text. I believe using immutable strings is not uncommon, as it allows an
EQ-test in display update.
-------
∂23-Jun-86 1816 Moon@QUABBIN.SCRC.Symbolics.COM Re: portability of pathnames
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 18:16:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12526; Mon 23-Jun-86 21:14:15 EDT
Date: Mon, 23 Jun 86 21:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: portability of pathnames
To: NGALL@G.BBN.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]23-Jun-86 11:11:44.NGALL>
Message-ID: <860623211400.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 23 Jun 1986 11:11-EDT
From: NGALL@G.BBN.COM
....
The point I am trying to make is that pathnames really should be 100%
implementation independent, including the contents of each of the
components....
Get your hands on a Symbolics document set and read about Logical
Pathnames. If I understand your requirements, Logical Pathnames are
exactly what you're looking for. When they (we) were looking at the
Zetalisp pathname system, most of the Common Lisp designers would not
accept logical pathnames because they didn't see any use for them.
It probably was also because logical pathnames were never explained
very well. Perhaps we ought to be rethinking that decision now.
If you get a chance to look at that documentation, I'm curious to
hear your opinion about whether that, or something like it, should
be added to Common Lisp.
∂23-Jun-86 1823 FAHLMAN@C.CS.CMU.EDU Argument Lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jun 86 18:23:10 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Jun 86 21:23:17-EDT
Date: Mon, 23 Jun 1986 21:23 EDT
Message-ID: <FAHLMAN.12217236274.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Subject: Argument Lists
In-reply-to: Msg of 23 Jun 1986 19:51-EDT from Pavel.pa at Xerox.COM
It is not required that an
implementation signal an error when there are either too many or too few
arguments...
I would have sworn that implementaitosn were required to signal an error
in this case, but a scan of CLtL seems to indicate that you are right.
The section on argument lists consistently says "is an error" and not
"signals an error". I can't remember (or imagine) why these cases
aren't required to signal an error, and I think this should be fixed.
Does anyone disagree? Are there any implementations out there that
don't signal errors when a function is given too many or too few args?
-- Scott
∂23-Jun-86 1831 KMP@YUKON.SCRC.Symbolics.COM portability of pathnames
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 18:30:40 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 43011; Mon 23-Jun-86 15:50:51 EDT
Date: Mon, 23 Jun 86 15:50 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: portability of pathnames
To: Fahlman@CMU-CS-C.ARPA
cc: SANDRA@UTAH-20.ARPA, JAR@MIT-MC.ARPA, Moon@SCRC-STONY-BROOK.ARPA,
KMP@SCRC-STONY-BROOK.ARPA, COMMON-LISP@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12216964464.BABYL@C.CS.CMU.EDU>
References: <860530014715.8.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<12210074365.15.LOOSEMORE@UTAH-20.ARPA>,
The message of 29 May 86 16:21-EDT from Jonathan A Rees <JAR@MIT-AI.ARPA>,
<12210693019.8.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860623155040.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sun, 22 Jun 1986 20:30 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE at UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
I'm going through old mail to make a list of issues we need to settle,
or at least work on. I came across your complaint about portability of
pathnames and the problems with make-pathname. I was just wondering if
you had anything specific to propose. If not, I'll just add this to the
agenda of things we collectively need to think about, but I'm not sure
there's a good solution to be had.
By the way, in my work with Macsyma I've seen most of the same problems
as Sandra mentioned in her message that kicked off this line of conversation.
She sounded in that message like she expected to get dumped on, but I
hope that she's neither dumped on nor ignored. Most of those comments were
very to the point.
I do take very minor issue with her remark that the package issue seems
a small one next to the other issues she cited. My reason for pushing so
hard to get these package issues resolved is that they impede everyone's
ability to get a foothold in a Lisp they're trying to port to. If we can't
get expressions to read the same in each each Lisp, then we're stripped
even of the ability to talk about language problems at the level of
expressions and must too frequently resort to discussions of the meaning
of source text. Also, in practice, implementation-specific workarounds are
something you can get to much more easily once the syntactic barriers are
resolved.
But I don't mean to diminish the importance of these other issues. Pathnames
are a horror to use in CL. Here's a list of the gripes I have with pathnames
which come to mind just off the top of my head; I'm sure if I though harder
I could think of others. Maybe Sandra could add some of her favorites...
* Canonical case. If you study the Symbolics pathname system, you'll note
that elaborate pains are taken to make the case of the components
be stored in uppercase for interchange purposes even if they're
composed as a namestring in another case. This allows the internal
representation of the Unix pathname /joe/math.text and the Tops-20
pathname <JOE>MATH.TEXT to use the same internal notation, with a
name of "MATH" and type of "TEXT", and allows cross-file-system
merging to be done correctly. The result of the current system is
that one must write gross things like:
(MAKE-PATHNAME :NAME THE-GIVEN-NAME
:TYPE (IF *LOWERCASE-FILENAMES-P* "text" "TEXT"))
and initialize the *LOWERCASE-FILENAMES-P* variable on the basis of
implementation-specific information. As Moon points out, the
Symbolics pathname system does this sort of thing invisibly, and
people interested in how to fix this should study the documentation.
It may seem hairy, but a portable file system interface is going to
necessarily be somewhat hairy just because of the variance of file
systems. I think given the constraints, it's not gratuitously hairy.
* What can go in a host slot? CLtL don't say whether a Lisp
implementation on host "FOO" is required to treat :HOST "FOO"
the same as :HOST NIL or :HOST "" in MAKE-PATHNAME. In fact,
nothing says whether "FOO:" or "FOO::" might be allowed (depending
on what the native notation was for hosts was); I definitely don't
think they should be, but there's nothing I can find protecting me
from an implementation making this the -only- way to notate a host.
* What can go in a directory slot? CLtL says it can hold a string,
but it doesn't say whether the string contains any notational
devices. eg, on VMS, is "FOO" ok for a directory or do you want
"[FOO]". "FOO" would seem the most portable, since it doesn't get
involved in the fact that TOPS-20 might want "<FOO>" and the LispM
might want ">FOO>" but it all doesn't matter much anyway because if
you want to talk about subdirs, "FOO.BAR" doesn't completely hide the
implementation because it works for systems that use the notation
"<FOO.BAR>" or "[FOO.BAR]" but not that use ">FOO>BAR" or "/FOO/BAR".
Without this much information, the kinds of operations you can do
on the contents are unreasonably limited. On the LispM, you say
:DIRECTORY "JOE" but in VAXLISP you say :DIRECTORY "[JOE]". The
LispM idea of allowing this to contain a list of directory names,
as in ("FOO" "BAR") to mean /FOO/BAR or >FOO>BAR> is clearly more
reasonable and I can't imagine why it was not adopted.
* Canonical types. The extension which is used for certain standard
kinds of files varies from implementation to implementation. eg,
some systems call text files .txt and others .text. Some call
lisp files .lsp, others .lisp, and others .clisp. Some call binary
files .BIN, others .FAS, and so on. It would be nice if we'd
adopted the LispM's canonical type system such certain dignified
file types could be predefined for use with portable programs.
Thus, (MAKE-PATHNAME :NAME "FOO" :TYPE :LISP) could refer to
"FOO.LISP" in some implementations, "foo.l" in others, etc.
* This business about semi-standard features like :NEWEST and :OLDEST
is a pain. We need those features, but we should fully enumerate the
entire set of possible contents and exactly what they denote, even
if not everyone supports them all. It should be possible to construct
a program that would be "ready for anything". Perhaps each
implementation could keep a list of which keywords were valid for
that implementation.
* No way is provided for creating a relative pathname. This would
be very useful for merging purposes even on systems which don't
provide a namestring syntax for pathnames. It is especially
essential in the absence of a clear specification of what the
directory slot contains.
* On issue is that there are so many fields which are allowed to
contain implementation-dependent gunk as to make those fields
are effectively write-only.
* Printing pathnames. We provide no convenient way to print a
pathname. On the LispM you can do (FORMAT T "~A" pathname) but
not all implementations support that because CLtL doesn't say
it should work. Doing (FORMAT T "~A" (NAMESTRING pathname))
seems dumb since, among other things, it forces gratuitous consing.
* How do you compare pathnames? EQUAL pathnames are not obliged
to be EQ. Since pathnames contain all these options for
implementation-dependent featurism, the user is not able to
write a PATHNAME-EQUAL. As far as I can tell, an implementation
in which a directory slot of "FOO.BAR" and ("FOO" "BAR") are
equivalent is not constrained to return T for EQUAL on two
pathnames which contain identical things except one uses
"FOO.BAR" and the other uses ("FOO" "BAR"). Indeed, even doing
(EQUAL (NAMESTRING X) (NAMESTRING Y)) isn't good enough because,
for example, VAX VMS allows logical names like "FOO:[.BAR]X.Y" to
expand into "DEV1A:[FOO][.BAR]X.Y". I don't care if
"FOO:[.BAR]X.Y" is PATHNAME-EQUAL to "DEV1A:[FOO][.BAR]X.Y"
because that's a semantic issue that may get caught up in how
the FOO logical device is implemented, but I do care that
"DEV1A:[FOO][.BAR]X.Y" and "DEV1A:[FOO.BAR]X.Y" are PATHNAME-EQUAL
because that's just a syntactic issue ... but I see no way of
writing a portable PATHNAME-EQUAL.
* I consider it to be a complete bug (and the only one that I've
seen which I believe to also be a bug in the Symbolics pathname
system) that you can't create a non-hosted pathname. eg, in
the case of someone doing
(MERGE-PATHNAMES "" "FOO")
and later planning to do
(MERGE-PATHNAMES * "JOE::")
where "::" is the host syntax used by the book, if you force the
first merge to put a host on, then the second merge won't pick
up the "JOE" and the wrong thing will happen. This actually came
up in MACSYMA and I was forced to invent my own pathname system
which holds a CL pathname in a slot and also holds host-valid-p
info that it keeps set to NIL after the first merge above (which
must be done via MY-MERGE-PATHNAMES, not CL's MERGE-PATHNAMES)
so that MY-MERGE-PATHNAMES can correctly do the second merge.
* The phrase "in which case no parsing is needed, but an error
check may be made for matching hosts" at the end of the first
paragraph of the description of PARSE-NAMESTRING on p414 is
an invitation to disaster since we don't specify how to obtain
even the current machine's host name or in what syntax it should
be presented in order to make this function happy. For example,
(PARSE-NAMESTRING "FOO.LISP") in VAXLISP might return
#S(PATHNAME :HOST "PETER" :DEVICE NIL :DIRECTORY NIL
:NAME "FOO" :TYPE "LISP" :VERSION NIL)
but (PARSE-NAMESTRING "FOO.LISP" "PETER")
errs telling me that host "" and "PETER" conflict. I might
report this as a bug and maybe they'd even fix it for me but
I'd have nothing to fall back on if they disagreed because CLtL
certainly doesn't come out and claim it's a bug.
* The description of the pathname system offers no examples of
using it any non-trivial way. All the examples use strings as
arguments, but that's just the problem. In portable applications,
strings just don't work. Sometimes, you're merging something that
was typed in by the user but rarely is it being merged with something
else typed by the user. The other thing is often something your
program wanted to have wired in. If you tried to write even the
simplest program using the given primitives in an even slightly
non-trivial way, the problem would become apparent. eg, try to
figure out how to specify the examples on p141 or p415 in a
portable way. To put yourself in the right frame of mind,
replace "DUMPER" on p414 with "MACSYMA" or "KEE" or "MYCIN" or
something that you don't think of as TOPS-20 specific. The
example on p415 is hard just as it is, for exactly the reasons
of canonical types I've mentioned above. What am I expected to
write? Top of p423 is the only place CLtL tries to do this, and
it more or less succeeds in this trivial case ... except for the
fact MERGE-PATHNAME-DEFAULTS isn't in the index and I suspect
never made it into the spec. Any way you cut it, these three
examples just don't do enough to illustrate what you can and
can't do with the given primitives.
I do think pathnames useful only for the most trivial purposes in CL.
I don't think this means we should flush them. I think we should
seriously study systems, particularly those offered by the LispM
vendors, where there's been success in dealing with multiple file
systems, and then I think we should agree on the additional mechanisms
necessary to make things really work.
∂23-Jun-86 1859 JAR@AI.AI.MIT.EDU Argument lists
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 23 Jun 86 18:56:56 PDT
Date: Mon, 23 Jun 86 21:57:45 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Argument lists
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA, Pavel.pa@XEROX.COM
In-reply-to: Msg of Mon 23 Jun 1986 21:23 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <[AI.AI.MIT.EDU].60667.860623.JAR>
Date: Mon, 23 Jun 1986 21:23 EDT
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
The section on argument lists consistently says "is an error" and not
"signals an error". I can't remember (or imagine) why these cases
aren't required to signal an error, and I think this should be fixed.
Does anyone disagree? Are there any implementations out there that
don't signal errors when a function is given too many or too few args?
There are plenty of Lisp and Scheme implementations which have a mode
in which such errors are not signalled or reliably detected. The two
which spring to my mind are Maclisp and T, but I suspect that any Lisp
that has a similar go-for-the-speed feature (PSL? Rutgers/UCI Lisp?
...) will fail to signal an error when a compiled function of a fixed
number of arguments is passed a wrong number of arguments. I can't
say I know of any such Common Lisp implementation, but it's certainly
easy to imagine one.
I don't see why this situation should be any different from any other
kind of domain error, like AREF'ing out of bounds. You can certainly
get speed improvements on stock hardware if you don't check number of
arguments (you can eliminate a compare instruction, save space, etc.).
Consistency is more important than speed, of course: if, for whatever
reason, an error must be signalled in this case, then so should errors
be signalled in most places which are now defined to "be an error".
Otherwise, on what principle do you distinguish these two kinds of
situation?
Jonathan
∂23-Jun-86 1948 Pavel.pa@Xerox.COM Re: Argument Lists
Received: from XEROX.COM by SU-AI.ARPA with TCP; 23 Jun 86 19:48:40 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUN 86 19:48:49 PDT
Date: 23 Jun 86 19:48 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Argument Lists
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Mon,
23 Jun 86 21:23 EDT
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <860623-194849-2250@Xerox>
Are there any implementations out there that
don't signal errors when a function is given too many or too few args?
In Interlisp, it is not an error to be given extra arguments (they are
silently thrown away) or too few (all arguments are implicitly optional
and default to NIL). While Xerox Common Lisp will signal an error in
such cases, we will also provide a setting of the optimize declarations
that will disable the checking for performance reasons.
Pavel
∂23-Jun-86 1951 FAHLMAN@C.CS.CMU.EDU Argument lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jun 86 19:51:30 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Jun 86 22:51:26-EDT
Date: Mon, 23 Jun 1986 22:51 EDT
Message-ID: <FAHLMAN.12217252319.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Argument lists
In-reply-to: Msg of 23 Jun 1986 21:57-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Yes, you're right. Wrong number of arguments should be treated like
AREF'ing out of bounds or type violations. The manual currently says
that these things are errors, but not that they must signal an error.
A good implementation will signal errors in most of these cases unless
compiled for maximal speed and minimal safety, but implementations are
not currently required to do this.
You ask about philosophy. Here's my current view -- it has evolved a
bit in the last couple of years:
There are three good reasons to document something as "being" an error,
but not as "signalling" one: first, it might be a place where we imagine
someone will want to extend the language, and where we want to leave
that possibility open; second, it might be an error that (perhaps only
on some architectures) is just impossible to detect with a reasonable
amount of effort; third, it might be a place where a few cycles can be
saved by not checking for the error.
It seems to me that, if we were doing this from scratch, we ought to
treat these cases differently. Specifically, I would go with four
classes of errors:
1. Errors that must always be signalled, and that portable code can
count on having signalled. These are errors where little speed-up would
result from allowing them to go undetected.
2. Errors that must normally be signalled, but that need not be if code
is compiled with safety = 0. Most of the current "is an error"
conditions, including wrong number of args, out-of-bounds array refs,
and most type violations, would fall in here.
3. Errors that are too hard to detect, and which need not be signalled.
Non-terminating code might be an example.
4. Errors that must be signalled unless an implementation deliberately
chooses to extend the language in this area, and documents that it has
done so. I'm not sure how much of this we ought to allow.
I suspect that this is too large a change to think about for the current
set of revisions. No legal and portable user code would be affected,
but I suspect that some implementations would require a lot of revision
in order to comply with the tightened requirements of case 2.
-- Scott
∂23-Jun-86 1959 FAHLMAN@C.CS.CMU.EDU Argument Lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jun 86 19:58:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Jun 86 22:59:02-EDT
Date: Mon, 23 Jun 1986 22:58 EDT
Message-ID: <FAHLMAN.12217253704.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Subject: Argument Lists
In-reply-to: Msg of 23 Jun 1986 22:48-EDT from Pavel.pa at Xerox.COM
In Interlisp, it is not an error to be given extra arguments (they are
silently thrown away) or too few (all arguments are implicitly optional
and default to NIL). While Xerox Common Lisp will signal an error in
such cases, we will also provide a setting of the optimize declarations
that will disable the checking for performance reasons.
The info about Max and Min args must be around at runtime if you do the
checking. Do you plan to eliminate the arg-count info if the users
turns on this optimization, or will the info still be around?
-- Scott
∂23-Jun-86 2216 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Error Checking in SUBSEQ
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 22:16:08 PDT
Received: from umass-cs by csnet-relay.csnet id al23860; 24 Jun 86 1:12 EDT
Date: Mon, 23 Jun 86 13:22 EST
From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To: Common-Lisp@SU-AI.ARPA
Subject: Error Checking in SUBSEQ
I feel strongly that it is a bad idea to spend effort looking for
weird ways to interpret meaningless arguments to functions. The only
MAIL
advantage to this is that it increases the functionality of CL without
increasing the number of functions in it, a dubious advantage.
This amounts to the same thing as "overloading operators" in more ugly
(i.e. traditional) programming languages, which is known to make it
hard for compilers and programmers.
It is much better to define new functions (or syntactically distinguishable
variants, such as :FROM-END) for new functionality. This allows the
programmer to tell the compiler/computer much more about his intended
use of the function. This enables the language implementor to support
more fine-grained error checking, and better compilations.
Several years ago while I was working on the editor for NIL, the unlderlying
error checking facilities were improved. This showed several cases
where I had called %STRING-SUBSEQ as if it took (string start end)
arguments, instead of (string start count) arguments. I don't
remember what effect this had, but the bug had been there for a long time.
As far as I am concerned it is better to decrease functionality so that
error checking can be improved than to increase functionality at the
expense of error checking. Error checking is our friend.
∂23-Jun-86 2225 MURRAY%cs.umass.edu@CSNET-RELAY.ARPA Argument-lists and friends
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 22:24:53 PDT
Received: from umass-cs by csnet-relay.csnet id ar23860; 24 Jun 86 1:14 EDT
Date: Mon, 23 Jun 86 14:59 EST
From: MURRAY%cs.umass.edu@CSNET-RELAY.ARPA
To: common-lisp@SU-AI.ARPA
Subject: Argument-lists and friends
I asked for this function a while ago. I feel handicapped without
being able to quickly see the arglist to a function.
Without this function, we now put the arglist in the docstring,
which is probably a good idea anyway. But that does require you
to have a docstring for the function. That may be fine for
user-interface, but the more important problem is for it to
be program accessable.
I think it is important that a common-lisp interpretor can be written
in common-lisp. To do this, there are three things that my Visual Stepper
has to hack in an implemention dependant way:
1. What the argument list is to a function. For this I need
the entire arglist, with &AUX variables and init forms as well.
If a system provides anything less, it is useless except to
find the minimum and max arg count.
2. The body to the function.
3. Whether a binding should be special.
For uncompiled objects, the first two things should be accessable
without any overhead. For compiled objects, it may be asking to much
for this information. In this case, you should
at least be able to get the min and max number of args, to do
code analysis. I think the following proposed functions should be
optional in common-lisp, but strongly encouraged to be supported:
FUNCTION-ARGLIST that takes a symbol and returns the DEFUN supplied
argument-list, and a second value of T, if the first value is
meaningful. If the second value is NIL, then the first value is meaningless.
FUNCTION-BODY takes a symbol and returns the body of the defun
(with the BLOCK around it), and again a second value indicating the
validity of the first one.
FUNCTION-ARGCOUNT takes a symbol and returns two values, minimum
argcount and max argcount, or NIL for both indicating invalidity.
Each of this functions should signal an error if the symbol is not
a function.
In the case of a macros, we could have analogous MACRO-xx functions,
so one could interpret macro expansions. Alternatively, the above
functions could take any function-object as well as a symbol, so
*macroexpand-hook* could be used to interpret macro expansions, giving
the function-object argument to the above functions.
Just to complete my need, I propose SPECIAL-VARIABLE-P to return
T, if a symbol is globally special.
Kelly Murray
∂24-Jun-86 0002 nttlab!kurims!yuasa@kurims.kurims.kyoto-u.junet defconstant
Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 24 Jun 86 00:02:29 PDT
Received: by su-shasta.arpa; Tue, 24 Jun 86 00:00:34 PDT
From: nttlab!kurims!yuasa@kurims.kurims.kyoto-u.junet
Received: by nttlab.ntt.junet (4.12/5.0) with TCP; Tue, 24 Jun 86 14:40:16 jst
Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet)
id AA00961; Tue, 24 Jun 86 13:07:15+0900
Date: Tue, 24 Jun 86 13:07:15+0900
Message-Id: <8606240407.AA00961@kurims.kurims.kyoto-u.junet>
To: nttlab!Shasta!common-lisp@su-ai.arpa
Subject: defconstant
Cc: nttlab!Shasta!FAHLMAN@c.cs.cmu.edu, nttlab!Shasta!NGALL@bbng.arpa
>From: Shasta!NGALL@G.BBN.COM
>Message-Id: <[G.BBN.COM]20-Jun-86 22:29:37.NGALL>
>
>File foo contains:
>
>(defconstant const ...)
>...
>
>File bar contains:
>
>(defun zap (x)
> ... (reference const x) ...)
>
>Now suppose that I compile file bar in an environment in which I have
>already loaded foo. Thus the compiler will recognize that the
>reference to const in zap is a reference of a constant.
>
>....
>
>But how about an implementation that does the following: It
>substitutes a reference to a slot in the compiled function's "constant
>vector" (i.e., the piece of data where most implementations store
>constant values). BUT it does not init the slot at compile time (like
>most implementations), instead, it generates code that will init. the
>slot to the value that const has at load time!
>....
>
>What do you think? By the way, thre does exist such an
>implementation: KCL.
>
> -- Nick
Our implemenatation for constant references in compiled code is based on
the following statement of CLtL page 68.
DEFCONSTANT name initial-value [doc] [Macro]
...
DEFCONSTANT ... does assert that the value of the variable NAME is
*fixed* and does license the compiler to build assumptions about the
value into programs being compiled.
My interpretation is that the compiler can safely assume that variable NAME
will never be MAKUNBOUNDed. With this interpretation, Nick's example above
is certainly an error. As far as I know, this interpretation of mine does
not contradict any CLtL statements, as Scott said in his message:
>From: "Scott E. Fahlman" <Shasta!Fahlman@C.CS.CMU.EDU>
>Subject: defconstant
>In-Reply-To: Msg of 20 Jun 1986 22:29-EDT from NGALL at G.BBN.COM
>
>I agree with Nick's analysis. A reference to a constant may be compiled
>as a variable reference or the value of the constant at compile time may
>be wired into the code, but if the latter is done, this should not
>depend on the constant having been initialized at load time. I agree
>that the manual is too vague on this point, and should be clarified.
If my interpretation is not what CLtL intends, I am very glad to change
our implementation, whether or not the intension is stated explicitly in CLtL.
However, before doing the change, let me tell you some details about KCL.
>I suspect that KCL handles Defconstant this way in order to optimize the
>use of lists as constants, while still observing the requirement that
>all references to the constant must be EQL to one another, but this is a
>very tricky business and is probably not worth the trouble it takes to
>get it right.
>
>-- Scott
It IS worth the trouble!! The KCL loader, when it loads a compiled code file,
stores the values of constants into fixed locations (NOT into a "constant
vector" as Nick guessed). Each reference to a constant within a compiled code
directly refers to the fixed location. This referencing operation IS faster
than retrieving the value from the symbol cell, which requires some kind of
indexing (hardware indexing, perhaps). (The portable C code generated by
the KCL compiler looks as if it references constants by indexing, but this is
one of the well-known C fakes commonly used by C programmers.)
-- Taiichi
∂24-Jun-86 0019 Pavel.pa@Xerox.COM Re: Argument Lists
Received: from XEROX.COM by SU-AI.ARPA with TCP; 24 Jun 86 00:19:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 86 00:18:40 PDT
Date: 24 Jun 86 00:15 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Argument Lists
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Mon,
23 Jun 86 22:58 EDT
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <860624-001840-2332@Xerox>
The info about Max and Min args must be around at runtime if you do the
checking. Do you plan to eliminate the arg-count info if the users
turns on this optimization, or will the info still be around?
The info about min and max need only exist implicitly in the compiled
code, if the number-check is implemented in macro-code. If it's done in
microcode as a part of function call, then it will likely be a part of
the function header and thus considerably easier to get at. In the
former case, turning on the optimization would remove the information.
Pavel
∂24-Jun-86 0314 SARASWAT@C.CS.CMU.EDU Pl. put me on the list.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 24 Jun 86 03:14:06 PDT
Received: ID <SARASWAT@C.CS.CMU.EDU>; Tue 24 Jun 86 06:14:16-EDT
Date: Tue 24 Jun 86 06:14:16-EDT
From: vijay <Vijay.Saraswat@C.CS.CMU.EDU>
Subject: Pl. put me on the list.
To: common-lisp@SU-AI.ARPA
Message-ID: <12217332943.37.SARASWAT@C.CS.CMU.EDU>
vas@k.cs.cmu.edu
Thanks,
Vijay.
-------
∂24-Jun-86 0808 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Argument Lists and ADVISE
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 24 Jun 86 08:08:11 PDT
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a017573; 23 Jun 86 21:02 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Mon, 23 Jun 86 20:55:31 -0100
Message-Id: <23498.8606231955@aiva.ed.ac.uk>
To: KMP@scrc-stony-brook.arpa, NGALL@bbng.arpa
Subject: Re: Argument Lists and ADVISE
Cc: COMMON-LISP@su-ai.arpa, Fahlman@c.cs.cmu.edu
Date: 23 Jun 1986 12:31-EDT
From: NGALL@arpa.bbng
Subject: Re: Argument Lists
Without information as to the number of required,
optional, and (in some implementations?) keyword arguments (and in the
case of keyword arguments, the names of the keywords), the
encapsulation function will be forced to do unnecessary consing
(because it will have to use &rest) and use a less efficient form of
function calling (in most impl.), APPLY.
If you can't find out the argument list, you can of course still write
something like ADVISE without using &REST provided that the user must
specify an argument list for the new definition. This is not such a bad
thing, because the user might, after all, want to advise the function to
take different arguments. And you can avoid APPLY if the user has to
explicitly call the old definition using a name like FORWARD or OLD-f
(it has to be distinct from the actual function name because the new
definition may want to call itself).
The syntax could be like DEFUN, e.g., from my Franz .lisprc file:
(define-embedding putd (name def)
(if (and *notice-redefinitions* (getd name))
(msg name " redefined (putd)" N))
(call-forward name def))
This is not to say that ARGUMENT-LIST wouldn't be useful, though.
-- Jeff
∂24-Jun-86 0949 NGALL@G.BBN.COM Re: defconstant
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 24 Jun 86 09:49:18 PDT
Date: 24 Jun 1986 12:47-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: defconstant
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]24-Jun-86 12:47:31.NGALL>
In-Reply-To: <8606240407.AA00961@kurims.kurims.kyoto-u.junet>
Date: Tue, 24 Jun 86 13:07:15+0900
From: nttlab!kurims!yuasa@kurims.kurims.kyoto-u.junet
To: nttlab!Shasta!common-lisp@su-ai.arpa
Subject: defconstant
Message-ID: <8606240407.AA00961@kurims.kurims.kyoto-u.junet>
...
Our implemenatation for constant references in compiled code is based on
the following statement of CLtL page 68.
DEFCONSTANT name initial-value [doc] [Macro]
...
DEFCONSTANT ... does assert that the value of the variable NAME is
*fixed* and does license the compiler to build assumptions about the
value into programs being compiled.
My interpretation is that the compiler can safely assume that variable NAME
will never be MAKUNBOUNDed. With this interpretation, Nick's example above
is certainly an error. As far as I know, this interpretation of mine does
not contradict any CLtL statements, as Scott said in his message:
I have been thinking about this issue for a while, and I now agree
with Taiichi: MAKUNBOUND is a form of assignment (it is even in the
assignment section of CLtL!); therefore my example violated the
assertion made by defconstant, since the value of the constant had no
value (i.e., a different value) at load time. What bothered me (and
still does) is that the "test" for violation occured at load time,
which I had never seen before nor expected. But I should not have let
my expectations color my interpretation of CLtL.
I even think that your implementation is "safer",
in that programmers are prevented from loading their files in a
different order than they compiled them.
Your handling of defconstant is simple and elegant, keep it in. But
be prepared for a few complaints since no (?) other implementation has
adopted your implementation technique.
-- Nick
∂24-Jun-86 1122 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument Lists
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 24 Jun 86 11:15:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 28102; Mon 23-Jun-86 14:40:13 EDT
Date: Mon, 23 Jun 86 14:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Argument Lists
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860623143926.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
There seems to be general agreement that there should be a standard
function that returns the minimum and maximum number of arguments
accepted by a given function. But what about functions that take
&KEY arguments?
∂24-Jun-86 1225 DCP@QUABBIN.SCRC.Symbolics.COM raster graphics
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 24 Jun 86 12:24:49 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12852; Tue 24-Jun-86 15:23:27 EDT
Date: Tue, 24 Jun 86 15:26 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: raster graphics
To: common-lisp@SU-AI.ARPA
Message-ID: <860624152614.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
I'm not on the special interest mailing list for graphics, so I don't
know if this has been touched on.
I encourage people who are considering proposing a CL graphics extension
to read the Symbolics 6.1 Release Notes regarding changes to arrays,
section 2.1.2, pages 5 through 12. The important concept is the
abstraction of 2 dimentional arrays of pixels into things called
rasters. The problem is that arrays are indexed by row,column and
rasters are indexed by x,y, but x=column,y=row. Therefore, if you
simply wrote raster code using AREF it would look awkward:
(aref some-array y x)
Along the same lines, rasters have width and height (generally thought
of in that order), but 2D arrays have rows and columns, and again, the
two are exchanged. The documentation includes a variety of functions to
deal with this, for example,
(raster-aref some-raster x y)
which turns into the appropriate aref, and
(decode-raster-array some-raster)
which returns as multiple values the width and height.
One reason we did this was to aid in the conversion from the
Release-6-and-before column major system to the CL-and-Release-7 row
major system. It allowed user source code to run in either system,
since the system provided the correct abstraction for each. I have
since come to believe the abstraction is worthy in its own right, and
hope that something like it would appear as part of a CL graphics
extension.
∂24-Jun-86 1235 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Why are char bits portable?
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 24 Jun 86 12:34:25 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 28407; Tue 24-Jun-86 00:37:43 EDT
Date: Tue, 24 Jun 86 00:35 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Why are char bits portable?
To: Masinter.PA@XEROX.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860619-123848-1153@Xerox>
References: <860620120906.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <860624003515.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[This message was sent last Friday but got returned due to some
network problems. Apologies to anyone who gets duplicate copies.]
Date: 19 Jun 86 12:32 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Why aren't char bits portable?
To: common-lisp@su-ai.ARPA
In-Reply-to: KMP%SCRC-STONY-BROOK:ARPA's message of Monday, June 9, 1986
12:23 pm
Message-ID: <860619-123848-1153@Xerox>
Char-bits aren't portable because they are a property of the physical
keyboard of the machine, and, most keyboards don't have bits that
correspond to them. ("Most" when enumerating all keyboards, computer
keyboards, keyboards on machines that run lisp, or even accepted
standards (DIN, ANSI) for keyboards.)
The best thing that a "portable" program can do to cope with the variety
of keyboards is twofold:
a) stick as much as possible within the set of standard characters
I assume the Japanese and IBM folks monitoring this discussion got a good
chuckle out of this one. I'm not sure what you mean by the set of standard
characters. Much of the CL spec is explicitly vague on the issue in order
to not preclude major changes in either character set or number of shift
chars provided.
b) mark the mapping of keys to characters as a clear
implementation-dependent part of programs that have to go beyond the
standard characters.
It's important to distinguish between implementation dependent behavior
and unpredictable behavior. Many things in Common Lisp are conceptually
well-defined even though they vary from implementation to implementation.
For example, the behavior of (1+ MOST-POSITIVE-FIXNUM) varies in detail
from implementation to implementation, but conceptually it does not. I
don't think that it's inappropriate to describe a program as having
useful commands bound to keys and to tell the user to type "?" to see a
list of the commands available.
You may have to do this for more reasons than just char bits. Maybe some
commands won't turn themselves on for other reasons. Eg, maybe some
setup code will not enable a certain command because MOST-POSITIVE-FIXNUM
is too small, or SINGLE-FLOAT-EPSILON is too big, or MACHINE-INSTANCE
returns NIL, or whatever.
The issue is much bigger than you make it out to be and if you claim it
to be fatal, then I claim you're attacking the whole notion of whether
CL can be portable... and I don't know if CL programs can ever be truly
portable, but I believe we can fix the language such that they can be
usefully portable.
Char-bits have no more place in the "standard" than does
double-bucky-coke-bottle.
[For those who don't know the term, a bucky bit is a generalized shift bit.
Control, Meta, Super, and Hyper are examples of such bits.]
This just isn't so. ITS Teco and ITS Emacs (which was ported to TOPS-20)
uses char bits quite portably, even though huge numbers of Emacs users
have only ASCII keyboards. The compatibility there works remarkably
gracefully. I had written a ton of programs which presumed that there
was a control bit. Teco's reader just took care of knowing what kind of
keyboard users were on, automatically translating ascii 001 to an A with
the Control bit set, etc. In the case of ;, which cannot be controllified
in ASCII, Emacs provided c-↑ as an prefix which would put a control bit
on the next char typed and pass that through. That way, I could type
c-↑ A and get a Control-A.
I also note that I use my Lisp Machine from home (on an Ambassador terminal)
and it does exactly the same trick. There's a front end processor which
takes c-↑ char into c-char, ESC char into m-char, c-] char into s-char, etc.
It even lets me type Resume, Abort, End etc. by c-← R, c-← A, c-← E, etc.
The point is that Lisp itself manages this, and any program I write sees
"normal" chars with bucky bits properly attached.
CL makes no statements about keyboards at all. There's nothing to say that
you don't have a tablet or voice input device managing your I/O. All we
say is that there are functions which read characters from streams. How
those characters end up being placed on the stream is pretty much left
up to the particular implementation.
So I just don't believe this argument.
As long as users of a portable program can get to all the relevant
commands, they don't tend to complain that their keyboard (which perhaps
has no META key) cannot type META-X. They just don't use META-X --
presumably they get the same functionality some other way. But users
who have a META key -do- complain when there's functionality available
and a free key that the functionality could be attached to. The current
CL strategy for bucky bits allows me the ability to deal with exactly
this problem -- attaching things to chars when they're available and not
when they're not. Why would you want to deny me the opportunity to do that?
Presumably if it wouldn't be a natural thing on your machine, then you
just don't implement the bits for your implementation, and my programs
will never try to use them, and your users won't think to complain
because they won't have funny shift keys that suggest they -should-
be using them.
Also, the presence of bucky bits in CL may help encourage some keyboard
vendors to add bits. If we say "let's not use these bits because no
keyboard vendors provide them", then I fear that at their next design
meeting, they'll say "let's not provide these bits because no languages
seem to use them". Someone's got to take the first step. We already
have. I see no reason to back off on it if people (eg, me) are using
it productively.
∂24-Jun-86 1303 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Common Lisp 2000
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 24 Jun 86 13:02:55 PDT
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a014975; 23 Jun 86 15:24 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Mon, 23 Jun 86 14:39:41 -0100
Message-Id: <19836.8606231339@aiva.ed.ac.uk>
To: Fahlman@c.cs.cmu.edu, snyder <@hplabs.hp.com:snyder@hplsny>
Subject: Common Lisp 2000
Cc: common-lisp@su-ai.arpa, eulisp%inria.uucp@Cs.Ucl.AC.UK
How do people feel about making changes like immutable/mutable whatevers
part of the ANSI/ISO standard instead of waiting for Common Lisp 2000?
I don't mean this particular change, which after all we might decide we
don't want at all, but rather changes of this magnitude. The EuLisp
proposals for the ISO standard do contain suggestions on this scale.
-- Jeff
∂24-Jun-86 1347 kempf%hplabsc@hplabs.HP.COM Re: raster graphics
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 24 Jun 86 13:46:03 PDT
Received: from hplabsc by hplabs.HP.COM ; Tue, 24 Jun 86 13:44:52 pdt
Received: by hplabsc ; Tue, 24 Jun 86 13:39:41 pdt
Date: Tue, 24 Jun 86 13:39:41 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8606242039.AA10124@hplabsc>
To: DCP@QUABBIN.SCRC.Symbolics.COM, common-lisp@SU-AI.ARPA
Subject: Re: raster graphics
How does this fit in with existing graphics standards (GKS, etc.)?
Jim Kempf kempf@hplabs
∂24-Jun-86 1707 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument lists
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 24 Jun 86 17:05:30 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 29030; Tue 24-Jun-86 16:17:23 EDT
Date: Tue, 24 Jun 86 16:19 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Argument lists
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>, Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA, Pavel.pa@XEROX.COM
In-Reply-To: <[AI.AI.MIT.EDU].60667.860623.JAR>
Message-ID: <860624161952.7.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon, 23 Jun 86 21:57:45 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Date: Mon, 23 Jun 1986 21:23 EDT
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
The section on argument lists consistently says "is an error" and not
"signals an error". I can't remember (or imagine) why these cases
aren't required to signal an error, and I think this should be fixed.
Does anyone disagree? Are there any implementations out there that
don't signal errors when a function is given too many or too few args?
There are plenty of Lisp and Scheme implementations which have a mode
in which such errors are not signalled or reliably detected. The two
which spring to my mind are Maclisp and T, but I suspect that any Lisp
that has a similar go-for-the-speed feature (PSL? Rutgers/UCI Lisp?
...) will fail to signal an error when a compiled function of a fixed
number of arguments is passed a wrong number of arguments. I can't
say I know of any such Common Lisp implementation, but it's certainly
easy to imagine one.
I don't see why this situation should be any different from any other
kind of domain error, like AREF'ing out of bounds. You can certainly
get speed improvements on stock hardware if you don't check number of
arguments (you can eliminate a compare instruction, save space, etc.).
Consistency is more important than speed, of course: if, for whatever
reason, an error must be signalled in this case, then so should errors
be signalled in most places which are now defined to "be an error".
Otherwise, on what principle do you distinguish these two kinds of
situation?
If CL does not come to require number of argument checking, I guess its
time to require *RSET to fill the gap. Seriously. Programmers should
be allowed to say "I want number of arguments checking, damn it" if the
system doesn't automatically provide that.
[After all, if you don't want number of argument checking, you can just
code your lambda list beginning with &optional and ending with &rest
ignore.]
∂24-Jun-86 1824 Pavel.pa@Xerox.COM Re: raster graphics
Received: from XEROX.COM by SU-AI.ARPA with TCP; 24 Jun 86 18:20:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 86 18:20:40 PDT
Date: 24 Jun 86 18:20 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: raster graphics
In-reply-to: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>'s message of Tue,
24 Jun 86 13:39:41 pdt
To: kempf%hplabsc@hplabs.HP.COM
cc: DCP@QUABBIN.SCRC.Symbolics.COM, common-lisp@SU-AI.ARPA
Message-ID: <860624-182040-2960@Xerox>
PLEASE!! Stop right here and move this discussion to the CL-Graphics
list! It doesn't belong here and does belong there!
Pavel
∂24-Jun-86 2036 NGALL@G.BBN.COM Re: Common Lisp 2000
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 24 Jun 86 20:36:06 PDT
Date: 24 Jun 1986 23:35-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Common Lisp 2000
From: NGALL@G.BBN.COM
To: jeff%aiva.edinburgh.ac.uk@CS.UCL.AC.UK
Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Cc: eulisp%inria.uucp@CS.UCL.AC.UK
Message-ID: <[G.BBN.COM]24-Jun-86 23:35:31.NGALL>
In-Reply-To: <19836.8606231339@aiva.ed.ac.uk>
Date: Mon, 23 Jun 86 14:39:41 -0100
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
To: Fahlman@c.cs.cmu.edu, snyder <@hplabs.hp.com:snyder@hplsny>
Subject: Common Lisp 2000
Message-ID: <19836.8606231339@aiva.ed.ac.uk>
How do people feel about making changes like immutable/mutable whatevers
part of the ANSI/ISO standard instead of waiting for Common Lisp 2000?
I don't mean this particular change, which after all we might decide we
don't want at all, but rather changes of this magnitude. The EuLisp
proposals for the ISO standard do contain suggestions on this scale.
-- Jeff
--------------------
I'd rather see our limited resources spent on trying to get what we
have into clear and consistent shape, so that we will really be able
to call CL a standard.
-- Nick
∂25-Jun-86 1549 SCHMIDT@SUMEX-AIM.ARPA Lisp & FP conference siting
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 25 Jun 86 15:49:08 PDT
Date: Wed 25 Jun 86 15:49:59-PDT
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Subject: Lisp & FP conference siting
To: Common-Lisp@SU-AI.ARPA
Message-ID: <12217732662.51.SCHMIDT@SUMEX-AIM.ARPA>
Who made the decision to locate the ACM Lisp & FP conference
away from AAAI? I doubt I'm the only would-be attendee who rates only
one conference per year and benefited from co-location. I don't
imagine there were a lot of people that had problems with the overlap
with the AAAI tutorials.
I joined the ACM in large part because I hoped I would find
out about this sort of thing in advance or (god forbid) vote on this
sort of issue. I attended both the '82 and '84 conferences and I
STILL haven't received any kind of announcement of this year's conference.
The exchanges in the Common-Lisp DL were the first I heard of it.
Are the location and timing for '88 decided yet? If the Lisp
& FP conference can't be held in conjunction with AAAI, it would better
be displaced by 6 months than 1 week in my opinion. Back-to-back
conferences require too much time away from work in one block.
--Christopher
P.S. I apologize in advance for sending this to the Common-Lisp
list, but I couldn't think of a more appropriate forum.
-------
∂25-Jun-86 1947 JAR@AI.AI.MIT.EDU Argument lists
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 25 Jun 86 19:47:04 PDT
Date: Wed, 25 Jun 86 22:47:28 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Argument lists
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA, Pavel.pa@XEROX.COM,
Fahlman@C.CS.CMU.EDU
In-reply-to: Msg of Tue 24 Jun 86 16:19 EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
Message-ID: <[AI.AI.MIT.EDU].61696.860625.JAR>
Date: Tue, 24 Jun 86 16:19 EDT
From: David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
If CL does not come to require number of argument checking, I guess its
time to require *RSET to fill the gap. Seriously. Programmers should
be allowed to say "I want number of arguments checking, damn it" if the
system doesn't automatically provide that.
[After all, if you don't want number of argument checking, you can just
code your lambda list beginning with &optional and ending with &rest
ignore.]
Sorry, I really don't understand your point. My point was NOT to take
a stand on whether or not checking was desirable; all I wanted to say
was that wrong-number-of-arguments is in the same class of error
situations as CAR of a symbol or out-of-nounds AREF. So if you think
CL must have *RSET-like switches controlling what happens when a wrong
number of arguments is passed [I don't think it should], it follows
that CL must also have *RSET-like things controlling what happens when
CAR of a symbol is taken. If you believe that wrong number of
arguments must signal an error [I don't think that should be dictated
either], then for consistency so must CAR of a symbol.
Jonathan
∂25-Jun-86 2156 GSB@AI.AI.MIT.EDU arglists, error checking
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 25 Jun 86 21:56:03 PDT
Date: Thu, 26 Jun 86 00:56:51 EDT
From: "Glenn S. Burke" <GSB@AI.AI.MIT.EDU>
Subject: arglists, error checking
To: common-lisp@SU-AI.ARPA
Message-ID: <[AI.AI.MIT.EDU].61762.860626.GSB>
In NIL we have arglist information as part of "debugging info" now.
This is separate from what is used for actually checking the arguments
to a (compiled) function, which is inline coded in the function entry
(sometimes with an out-of-line call, but the call is at the start of
the compiled function and occurs unconditionally). Using the optimize
declaration appropriately can make this check go away. &KEY is handled
out-of-line always, but the partitioning of arguments into
required/optional/rest is where the number-of-arguments check occurs,
and that precedes the &key parsing.
Anyway, this means that any kind of *RSET check would also have to be
done in some cumbersome fashion since the decision to check or not is
made at compile time.
∂26-Jun-86 0732 gls@Think.COM Lisp & FP conference siting
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 26 Jun 86 07:32:17 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Thu, 26 Jun 86 10:32:19 edt
Date: Thu, 26 Jun 86 10:33 EDT
From: Guy Steele <gls@Think.COM>
Subject: Lisp & FP conference siting
To: SCHMIDT@SUMEX-AIM.ARPA
Cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <12217732662.51.SCHMIDT@SUMEX-AIM.ARPA>
Message-Id: <860626103321.1.GLS@BOETHIUS.THINK.COM>
Date: Wed 25 Jun 86 15:49:59-PDT
From: Christopher Schmidt <SCHMIDT@SUMEX-AIM.ARPA>
Who made the decision to locate the ACM Lisp & FP conference
away from AAAI?
I didn't make the decision, nor do I have any official position at this
year's conference; but I was program chairman for the 1984 conference,
and local arrangements chairman for the 1982 conference, so I can speak
from experience.
I doubt I'm the only would-be attendee who rates only
one conference per year and benefited from co-location. I don't
imagine there were a lot of people that had problems with the overlap
with the AAAI tutorials.
Co-location caused a minor headache in 1982, namely that AAAI, being the
larger conference and planned further ahead, tended to use up resources
in the host city. It was difficult to find lecture halls and hotel
space. It was also necesssary to pick a banquet activity different from
the activities planned by AAAI.
Co-location caused a major headache in 1984. Overlap with tutorials was
not a problem, but despite our best efforts to coordinate, paper
sessions of the two conferences overlapped, because AAAI became larger
that year (3 full days instead of 2 1/2). This resulted in decreased
attendance.
I happen to be a sub-area chairman for AAAI this year, and so know
something about how it is organized as well. This year AAAI is running
five full days of paper sessions, for the most part with four or five
parallel tracks! Even if in the same city, the only way to avoid
conflict would have been to schedule the Lisp conference for the
preceding or following week. Furthermore, the facilities in
Philadelphia are not ideal, being spread out; AAAI by itself is going to
have to use shuttle buses.
I am in sympathy with your complaint; it's going to be hard for me, too,
to attend both of them. However, given that they have to be in separate
weeks, it's not that bad to zoom between Boston and Philadelphia over
the weekend. (Admittedly, that's easy for me to say, here in Boston.)
I joined the ACM in large part because I hoped I would find
out about this sort of thing in advance or (god forbid) vote on this
sort of issue. I attended both the '82 and '84 conferences and I
STILL haven't received any kind of announcement of this year's conference.
The exchanges in the Common-Lisp DL were the first I heard of it.
The call for papers appeared in the December 1985 SIGPLAN Notices; this
call indicated the conference site (MIT). The conference has been
listed in the Calendar of Events in the Communications of the ACM since
last November. Note that AAAI is not an ACM function. There was also a
mailing, which you should have received if you belong to one of the
relevant SIGs.
Are the location and timing for '88 decided yet? If the Lisp
& FP conference can't be held in conjunction with AAAI, it would better
be displaced by 6 months than 1 week in my opinion. Back-to-back
conferences require too much time away from work in one block.
--Christopher
I don't have the information to respond to this. I'm sure the
conference organizers are interested in feedback such as this. Some
questions of interest are: if both conferences are to be held in August
after all, should they be back-to-back or separated by a week or two?
Is it better to hold them on the same side of, say, Nebraska or on
different sides?
P.S. I apologize in advance for sending this to the Common-Lisp
list, but I couldn't think of a more appropriate forum.
-------
[Dick, I hate to do this to you, but...] I would say it is reasonable to
raise the issue on this mailing list, but please let's not have a hundred
flames follow on the same subject. It would be better to send comments
directly to this year's general chairman for the conference, who is:
Richard P. Gabriel
Lucid, Inc.
707 Laurel St.
Menlo Park, CA 94025
--Guy
∂26-Jun-86 0933 gls@Think.COM Argument lists: a proposal to shoot at
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 26 Jun 86 09:33:42 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Thu, 26 Jun 86 12:33:44 edt
Date: Thu, 26 Jun 86 12:34 EDT
From: Guy Steele <gls@Think.COM>
Subject: Argument lists: a proposal to shoot at
To: common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
Message-Id: <860626123445.9.GLS@BOETHIUS.THINK.COM>
In the following function descriptions, assume that the argument
function has Q required parameters and P &optional parameters, and that
R, K, or A is true iff the function has respectively a &rest, &key, or
&allow-other-keys lambda-keyword.
FUNCTION-MIN-ARGS function [Function]
Returns Q, the minimum number of arguments that must be supplied when
the function is called.
FUNCTION-MAX-ARGS function [Function]
Returns (AND (OR (NOT R) K) (+ Q P)), that is, the maximum number of
arguments, exclusive of arguments for keyword parameters, that may be
supplied when the function is called. A return value of NIL indicates
that there is no such maximum, that is, the function has a &rest
parameter and no &key parameters. (Note that if a function has keyword
parameters, exactly (+ Q P) arguments have to be supplied before the
arguments that will be interpreted for keyword parameters.)
FUNCTION-HAS-KEYWORD-PARAMETERS function [Function]
Returns two values, K and A.
FUNCTION-KEYWORD-PARAMETER-P function keyword [Function]
Returns two values. If the function directly accepts the keyword as the
name of a keyword parameter (that is, the keyword parameter appeared in
the parameter list of the function), then the values T T are returned.
If the function does not accept the keyword directly, but its parameter
list contained &allow-other-keywords, then the values T NIL are
returned. Otherwise the values NIL NIL are returned. Note that
FUNCTION-KEYWORD-PARAMETER-P may be correctly applied to any function,
even one that was not declared with &key (the values NIL NIL are always
returned for such a function).
FUNCTION-KEYWORD-PARAMETERS function [Function]
Returns a list of all keywords that the argument function accepts
directly. Note that FUNCTION-KEYWORD-PARAMETERS may be correctly
applied to any function, even one that was not declared with &key (an
empty list is always returned for such a function).
Point of design philosophy: &aux "parameters" aren't anybody's business
at this level of abstraction. I don't deny that for the sake of
debuggers this information, and such other information as the names of
parameters, may be desired.
--Guy
∂26-Jun-86 1618 NGALL@G.BBN.COM Re: Argument lists: a proposal to shoot at
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 26 Jun 86 16:17:52 PDT
Date: 26 Jun 1986 19:17-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Argument lists: a proposal to shoot at
From: NGALL@G.BBN.COM
To: gls@ZARATHUSTRA.THINK.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]26-Jun-86 19:17:24.NGALL>
In-Reply-To: <860626123445.9.GLS@BOETHIUS.THINK.COM>
Date: Thu, 26 Jun 86 12:34 EDT
From: Guy Steele <gls@Think.COM>
To: common-lisp@SU-AI.ARPA
Subject: Argument lists: a proposal to shoot at
Message-ID: <860626123445.9.GLS@BOETHIUS.THINK.COM>
In the following function descriptions, assume that the argument
function has Q required parameters and P &optional parameters, and that
R, K, or A is true iff the function has respectively a &rest, &key, or
&allow-other-keys lambda-keyword.
FUNCTION-MIN-ARGS function [Function]
Returns Q, the minimum number of arguments that must be supplied when
the function is called.
FUNCTION-MAX-ARGS function [Function]
Returns (AND (OR (NOT R) K) (+ Q P)), that is, the maximum number of
arguments, exclusive of arguments for keyword parameters, that may be
supplied when the function is called. A return value of NIL indicates
that there is no such maximum, that is, the function has a &rest
parameter and no &key parameters. (Note that if a function has keyword
parameters, exactly (+ Q P) arguments have to be supplied before the
arguments that will be interpreted for keyword parameters.)
Your encoding scheme does not let me see the number of
'probably-stack-based' parameters (i.e., P+Q) given a function that
has a &rest param and no &key params. This makes it impossible to
provide an encapsulation that would use &rest only where necessary (it
would force the use of a &rest parameter for all args beyond the
required parameters).
How about keeping the number of functions down and eliminating the
'encoding' in MAX-ARGS, and using correct terminology with the
following one-function alternative to FUNCTION-MIN-ARGS, -MAX-ARGS,
-HAS-KEYWORD-PARAMETERS, and -KEYWORD-PARAMETERS. I think
FUNCTION-KEYWORD-PARAMETER-P addresses an idiom common enough to
warrant its own function.
FUNCTION-PARAMETERS function [Function]
Returns Q, P, R, K, a list of keywords explicitly accepted by the
function (order undefined), and A. Note that if K is false, the list
is necessarily empty.
FUNCTION-KEYWORD-PARAMETER-P function keyword [Function]
Returns two values. If the function directly accepts the keyword as the
name of a keyword parameter (that is, the keyword parameter appeared in
the parameter list of the function), then the values T T are returned.
If the function does not accept the keyword directly, but its parameter
list contained &allow-other-keywords, then the values T NIL are
returned. Otherwise the values NIL NIL are returned. Note that
FUNCTION-KEYWORD-PARAMETER-P may be correctly applied to any function,
even one that was not declared with &key (the values NIL NIL are always
returned for such a function).
...
Point of design philosophy: &aux "parameters" aren't anybody's business
at this level of abstraction. I don't deny that for the sake of
debuggers this information, and such other information as the names of
parameters, may be desired.
Agreed.
--Guy
-- Nick
∂26-Jun-86 1748 lee%hplles@hplabs.HP.COM Case sensitive reading.
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 26 Jun 86 17:48:20 PDT
Received: from hplles by hplabs.HP.COM ; Thu, 26 Jun 86 17:46:34 pdt
Received: by hplles ; Thu, 26 Jun 86 17:47:06 pdt
From: Lee Schumacher <lee%hplles@hplabs.HP.COM>
Message-Id: <8606270047.AA06350@hplles>
Date: Thursday, June 26, 1986 17:47:03
Subject: Case sensitive reading.
To: common-lisp@su-ai
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
I no longer follow this mailing list, but i'm
told that someone recently suggested that
there be some mechanism for turning on case-sensitivity
in the reader. As evidence for a need for this, I recently
wrote a simple package to analyze some C code. I discovered,
to my annoyance, that the only way to preserve the case info
(which I needed) was to copy the read-token function from
the common lisp source, remove the char-upcase calls, and then make a new
readtable with each call to read-token replaced with a call to my
version ! Not good.
Lee Schumacher
-------
∂26-Jun-86 1814 FAHLMAN@C.CS.CMU.EDU Case sensitive reading.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jun 86 18:12:59 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 26 Jun 86 21:09:55-EDT
Date: Thu, 26 Jun 1986 21:09 EDT
Message-ID: <FAHLMAN.12218020270.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Lee Schumacher <lee%hplles@HPLABS.HP.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: Case sensitive reading.
In-reply-to: Msg of 26 Jun 1986 17:47-EDT from Lee Schumacher <lee%hplles at hplabs.HP.COM>
The Lisp reader was designed primarily for reading Lisp code. There are
all sorts of things in other computer languages that would tend to choke
it. Case sensitivity is one of them. It is unreasonable to expect that
there would be a few built-in switches you could throw to turn the Lisp
reader into a C parser or even a C tokenizer. On the other hand, there
are lots of built-in facilities that would make it a relatively
strightforward matter to write such a thing from scratch.
-- Scott
∂26-Jun-86 2014 FAHLMAN@C.CS.CMU.EDU Error Signalling
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jun 86 20:14:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 26 Jun 86 23:14:48-EDT
Date: Thu, 26 Jun 1986 23:14 EDT
Message-ID: <FAHLMAN.12218043005.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Error Signalling
In-reply-to: Msg of 26 Jun 1986 00:56-EDT from Glenn S. Burke <GSB at AI.AI.MIT.EDU>
We don't need anything like *RSET. Common Lisp provides the user with
an appropriate way of specifying whether speed or error checking is
preferred: the OPTIMIZE declaration. Most good implementations detect
and signal argument count, argument type, array bounds, and similar
errors, except when the user has indicated that speed is valued more
than safety (some use SPEED > SAFETY, others use SAFETY = 0). Actually,
that statement is somewhat backwards: signalling these errors
appropriately is one of my criteria for a "good implementation".
The question we should address is what we should say about such errors
in the standard for Common Lisp. There are three options:
1. The status quo: each of these things "is an error", but it is
entirely up to the implementor whether and under what circumstances to
detect and signal these errors.
2. The rigorous solution: For errors of the types described above, it is
REQUIRED that implementations signal an error in interpreted code. It
is also required that these errors be signalled in compiled code unless
(optimize (safety 0)) is in effect at compile time.
3. Sitting on the fence: The conditions stated in option 2 are not
required in the spec, but they are "recommended".
I think that 2, the rigorous solution, is clearly the best approach for
standardization and for portability of code. However, we should adopt
this only if there is a fairly strong consensus in its favor, and only
if it doesn't make too much toruble for existing implementations. If
those conditions are not met, we should go with the status quo. I'm
undecided about option 3. Should a spec get into the recommendation
business? In many cases where we can't actually require things,
recommendations may help to keep divergence to a minimum.
We will soon need to make a formal decision about what goes into the
spec. I'd like to know what people think of these three options --
please try to be brief. Also, if you represent an implementation group,
please indicate whether the requirement in option 1 would make real
trouble for you, regardless of whether you favor it. The question is
not whether you could install this by next Tuesday, but whether it would
be a problem to meet this tightened requirement in a release nine months
or a year from now.
-- Scott
∂26-Jun-86 2052 FAHLMAN@C.CS.CMU.EDU Argument lists: a proposal to shoot at
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jun 86 20:51:50 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 26 Jun 86 23:51:03-EDT
Date: Thu, 26 Jun 1986 23:51 EDT
Message-ID: <FAHLMAN.12218049604.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Argument lists: a proposal to shoot at
In-reply-to: Msg of 26 Jun 1986 19:17-EDT from NGALL at G.BBN.COM
Your encoding scheme does not let me see the number of
'probably-stack-based' parameters (i.e., P+Q) given a function that
has a &rest param and no &key params. This makes it impossible to
provide an encapsulation that would use &rest only where necessary (it
would force the use of a &rest parameter for all args beyond the
required parameters).
Sorry, maybe I'm being dense, but I don't understand this. What is it
that an encapsulation can do better if it can see P+Q ? Why do you want
to rip the lid off this particular black box?
-- Scott
∂27-Jun-86 0019 franz!fizzy!jkf@kim.Berkeley.EDU Re: Case sensitive reading.
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 27 Jun 86 00:19:36 PDT
Received: by kim.Berkeley.EDU (5.51/1.14)
id AA18214; Fri, 27 Jun 86 00:18:29 PDT
From: franz!fizzy!jkf@kim.berkeley.edu
Received: from fizzy by franz (5.5/3.14)
id AA29888; Thu, 26 Jun 86 22:36:21 PDT
Received: by fizzy (4.12/3.14)
id AA02675; Thu, 26 Jun 86 22:36:50 pdt
Return-Path: <fizzy!jkf>
Message-Id: <8606270536.AA02675@fizzy>
To: Lee Schumacher <ucbkim!hplabs.HP.COM!lee%hplles>
Cc: common-lisp@su-ai.arpa
Subject: Re: Case sensitive reading.
In-Reply-To: Your message of Thu, 26 Jun 86 17:47:03 GMT.
<8606270047.AA06350@hplles>
Date: Thu, 26 Jun 86 22:36:48 PDT
re:
I no longer follow this mailing list, but i'm
told that someone recently suggested that
there be some mechanism for turning on case-sensitivity
in the reader.
Our common lisp has a mechanism for turning on case sensitivity. It
is an extension. Write to me if you want more details.
- john foderaro
franz inc.
∂27-Jun-86 0721 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Error Signalling
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 07:21:42 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3301; 27 Jun 86 10:21:38-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 26404; Fri 27-Jun-86 10:22:22-EDT
Date: Fri, 27 Jun 86 10:20 EST
From: mike@a
To: Fahlman@C.CS.CMU.EDU
Reply-to: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: Error Signalling
Cc: common-lisp@SU-AI.ARPA
Date: Thu, 26 Jun 1986 23:14 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
.....
The question we should address is what we should say about such errors
in the standard for Common Lisp. There are three options:
1. The status quo: each of these things "is an error", but it is
entirely up to the implementor whether and under what circumstances to
detect and signal these errors.
I'd say this is a non-spec. It should be possible for an implementation
to detect ALL errors. To say something is an error, but to not
require the implementation to detect it is to make it impossible for
programmers to debug code (unless you like hex core dumps...)
2. The rigorous solution: For errors of the types described above, it is
REQUIRED that implementations signal an error in interpreted code. It
is also required that these errors be signalled in compiled code unless
(optimize (safety 0)) is in effect at compile time.
As far as I'm concerned, this is the only reasonable position to
take. In general, I think the phrase "is an error" in CLtL should be
interpreted as "signals an error unless action is taken to ignore the
condition through declarations." I don't see any difficulty in implementation
here for Gold Hill.
3. Sitting on the fence: The conditions stated in option 2 are not
required in the spec, but they are "recommended".
We will soon need to make a formal decision about what goes into the
spec. I'd like to know what people think of these three options --
please try to be brief. Also, if you represent an implementation group,
please indicate whether the requirement in option 1 would make real
I assume you mean option 2.
trouble for you, regardless of whether you favor it. The question is
not whether you could install this by next Tuesday, but whether it would
be a problem to meet this tightened requirement in a release nine months
or a year from now.
-- Scott
...mike beckerle
Gold Hill Computers
∂27-Jun-86 0722 kempf%hplabsc@hplabs.HP.COM Re: Case sensitive reading.
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 27 Jun 86 07:22:37 PDT
Received: from hplabsc by hplabs.HP.COM ; Fri, 27 Jun 86 07:21:19 pdt
Received: by hplabsc ; Fri, 27 Jun 86 07:22:08 pdt
Date: Fri, 27 Jun 86 07:22:08 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8606271422.AA07719@hplabsc>
To: Fahlman@C.CS.CMU.EDU, lee%hplles@HPLABS.HP.COM
Subject: Re: Case sensitive reading.
Cc: common-lisp@SU-AI.ARPA
The CL function READ-LINE (CLtL pg. 378) can be used to read in
general text without case conversion. Tokenization can then
be done by parsing this string.
Jim Kempf kempf@hplabs
∂27-Jun-86 0738 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Re: Argument lists: a proposal to shoot at
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 07:38:02 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3304; 27 Jun 86 10:37:26-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 26406; Fri 27-Jun-86 10:38:13-EDT
Date: Fri, 27 Jun 86 10:36 EST
From: mike@a
To: NGALL@G.BBN.COM
Reply-to: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: Re: Argument lists: a proposal to shoot at
Cc: gls@ZARATHUSTRA.THINK.COM, common-lisp@SU-AI.ARPA
Date: 26 Jun 1986 19:17-EDT
From: NGALL@G.BBN.COM
.......
Your encoding scheme does not let me see the number of
'probably-stack-based' parameters (i.e., P+Q) given a function that
has a &rest param and no &key params. This makes it impossible to
provide an encapsulation that would use &rest only where necessary (it
would force the use of a &rest parameter for all args beyond the
required parameters).
Sorry, but inferring anything about 'probably stack based' at run time
just turns my stomach. Why not ask how many are 'register based'?
Why not just call (disassemble ...)????
There are three kinds of things going on here. One is to somehow figure
out how to call a function so you can avoid a run time error, etc.
This is best served I think by enhancing (type-of ...) for funcallable
objects. The second is for programming environments, which is best
served by keeping argument lists around on a property list, or something,
since the idea is to inform a programmer how the call works, and to
give him some idea of the semantics of the arguments by allowing access
to the actual argument names.
The third, and most troublesome is so that programs can reason about
how arguments are passed, i.e., can do things like 'probably register
based', and so on. Why is this needed?
I think we should provide (arglist ...) which returns the literal
arglist of functions, to address user interface considerations.
We shouldn't break the function abstraction any more than that.
...mike beckerle
Gold Hill Computers
∂27-Jun-86 0753 hall@HOPKINS-EECS-BRAVO.ARPA Getting on the mailing list.
Received: from HOPKINS-EECS-BRAVO.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 07:53:15 PDT
Date: Fri, 27 Jun 86 10:43:45 EDT
From: Marty Hall <hall@hopkins-eecs-bravo.ARPA>
To: common-lisp@su-ai.ARPA
Subject: Getting on the mailing list.
I have heard that I could be added to the Common LISP mailing list
by requesting here. If that is OK, please add me. I am losing my uucp
access, so lists like Net.Lang.LISP are no longer available to me. Are there others like
that around?
Thanks!
Marty Hall
hall@hopkins-eecs-bravo.arpa
∂27-Jun-86 1144 gls@Think.COM Re: Argument lists: a proposal to shoot at
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 27 Jun 86 11:44:05 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Fri, 27 Jun 86 14:44:00 edt
Date: Fri, 27 Jun 86 14:45 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: Argument lists: a proposal to shoot at
To: NGALL@G.BBN.COM, gls@ZARATHUSTRA
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <[G.BBN.COM]26-Jun-86 19:17:24.NGALL>
Message-Id: <860627144507.7.GLS@BOETHIUS.THINK.COM>
Date: 26 Jun 1986 19:17-EDT
From: NGALL@G.BBN.COM
How about keeping the number of functions down and eliminating the
'encoding' in MAX-ARGS, and using correct terminology with the
following one-function alternative to FUNCTION-MIN-ARGS, -MAX-ARGS,
-HAS-KEYWORD-PARAMETERS, and -KEYWORD-PARAMETERS. I think
FUNCTION-KEYWORD-PARAMETER-P addresses an idiom common enough to
warrant its own function.
FUNCTION-PARAMETERS function [Function]
Returns Q, P, R, K, a list of keywords explicitly accepted by the
function (order undefined), and A. Note that if K is false, the list
is necessarily empty.
I have to admit (blush) that another design criterion I employed implicitly
was that it should be possible to acquire most of the information without
either consing on the fly or requiring an explicit pre-stored list of the
keywords.
In your proposal for FUNCTION-PARAMETERS, I observe that returning K
is redundant: K is true iff [(the keyword list is not empty) or A].
That's not to say that returning K separately isn't a good idea.
--Guy
-- Nick
--Guy
∂27-Jun-86 1334 NGALL@G.BBN.COM Re: Argument lists: a proposal to shoot at
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 13:34:07 PDT
Date: 27 Jun 1986 16:32-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Argument lists: a proposal to shoot at
From: NGALL@G.BBN.COM
To: gls@ZARATHUSTRA.THINK.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]27-Jun-86 16:32:34.NGALL>
In-Reply-To: <860627144507.7.GLS@BOETHIUS.THINK.COM>
Date: Fri, 27 Jun 86 14:45 EDT
From: Guy Steele <gls@Think.COM>
To: NGALL@G.BBN.COM, gls@ZARATHUSTRA
Subject: Re: Argument lists: a proposal to shoot at
In-Reply-To: <[G.BBN.COM]26-Jun-86 19:17:24.NGALL>
Message-ID: <860627144507.7.GLS@BOETHIUS.THINK.COM>
Date: 26 Jun 1986 19:17-EDT
From: NGALL@G.BBN.COM
How about keeping the number of functions down and eliminating the
'encoding' in MAX-ARGS, and using correct terminology with the
following one-function alternative to FUNCTION-MIN-ARGS, -MAX-ARGS,
-HAS-KEYWORD-PARAMETERS, and -KEYWORD-PARAMETERS. I think
FUNCTION-KEYWORD-PARAMETER-P addresses an idiom common enough to
warrant its own function.
FUNCTION-PARAMETERS function [Function]
Returns Q, P, R, K, a list of keywords explicitly accepted by the
function (order undefined), and A. Note that if K is false, the list
is necessarily empty.
I have to admit (blush) that another design criterion I employed implicitly
was that it should be possible to acquire most of the information without
either consing on the fly or requiring an explicit pre-stored list of the
keywords.
Yes. I worried about returning the list of keywords, when all the user
wanted to know was min and max args, for example. I guess I figured
that pre-stored lists weren't a very high price to pay. I'm
ambivalent about returning the list vs. returning the the number of
keyword args. and bringing back FUNCTION-KEYWORD-PARAMETERS.
In your proposal for FUNCTION-PARAMETERS, I observe that returning K
is redundant: K is true iff [(the keyword list is not empty) or A].
That's not to say that returning K separately isn't a good idea.
Not true. (lambda (&key)...) is legal.
--Guy
-- Nick
--Guy
-- Nick
∂27-Jun-86 1518 Moon@RIVERSIDE.SCRC.Symbolics.COM Re: Argument lists: a proposal to shoot at
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 15:17:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 30414; Fri 27-Jun-86 18:16:20 EDT
Date: Fri, 27 Jun 86 18:15 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Argument lists: a proposal to shoot at
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860627144507.7.GLS@BOETHIUS.THINK.COM>
Message-ID: <860627181505.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 27 Jun 86 14:45 EDT
From: Guy Steele <gls@Think.COM>
Date: 26 Jun 1986 19:17-EDT
From: NGALL@G.BBN.COM
How about keeping the number of functions down and eliminating the
'encoding' in MAX-ARGS, and using correct terminology with the
following one-function alternative to FUNCTION-MIN-ARGS, -MAX-ARGS,
-HAS-KEYWORD-PARAMETERS, and -KEYWORD-PARAMETERS. I think
FUNCTION-KEYWORD-PARAMETER-P addresses an idiom common enough to
warrant its own function.
FUNCTION-PARAMETERS function [Function]
Returns Q, P, R, K, a list of keywords explicitly accepted by the
function (order undefined), and A. Note that if K is false, the list
is necessarily empty.
I like one function to return all the information better than a bunch of
separate functions. As for whether it's better to return min-and-max or
required-and-optional, in all these years I've never made up my mind on
that point. I do think it's a good idea for the presence of &rest or &key
not to throw away the information about how many positional parameters
there are, even if some of the proposed uses for that information are
bad ideas. In the min-and-max model, max could be the maximum number
of positional parameters, thus you have to look at (OR R K) to know
whether this is actually the maximum you are permitted to pass.
I have to admit (blush) that another design criterion I employed implicitly
was that it should be possible to acquire most of the information without
either consing on the fly or requiring an explicit pre-stored list of the
keywords.
I don't understand how the information would be accessible at all if
there was not a pre-stored list. Perhaps you have some clever
implementation in mind? If this is really important, we could have both
FUNCTION-PARAMETERS and FUNCTION-KEYWORD-PARAMETER-P, with some way to
tell FUNCTION-PARAMETERS not to bother creating the list. But I like it
better with just one function. Anyway I know how to not be bothered
by consing on the fly.
In your proposal for FUNCTION-PARAMETERS, I observe that returning K
is redundant: K is true iff [(the keyword list is not empty) or A].
That's not to say that returning K separately isn't a good idea.
(defun foo (&key) ...) has some semantic meaning, namely that if this
function is ever extended it's going to take keyword parameters. If you
don't think this is a realistic example, see CLtL page 427.
I don't think clever elimination of the K return value is advisable.
∂27-Jun-86 1523 Moon@QUABBIN.SCRC.Symbolics.COM Error Signalling
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 15:21:54 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14356; Fri 27-Jun-86 18:20:15 EDT
Date: Fri, 27 Jun 86 18:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Error Signalling
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12218043005.BABYL@C.CS.CMU.EDU>
Message-ID: <860627181913.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 26 Jun 1986 23:14 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
The question we should address is what we should say about such errors
in the standard for Common Lisp. There are three options:
1. The status quo: each of these things "is an error", but it is
entirely up to the implementor whether and under what circumstances to
detect and signal these errors.
2. The rigorous solution: For errors of the types described above, it is
REQUIRED that implementations signal an error in interpreted code. It
is also required that these errors be signalled in compiled code unless
(optimize (safety 0)) is in effect at compile time.
3. Sitting on the fence: The conditions stated in option 2 are not
required in the spec, but they are "recommended".
#2 has always been the policy in Symbolics' implementation. That's
an implementation design decision. I don't feel qualified to judge
whether #2 should be the language specification, or whether it's
better for the language to permit laxer implementations.
∂27-Jun-86 1532 DSinger@SRI-KL.ARPA Re: Argument Lists
Received: from SRI-KL.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 15:32:40 PDT
Date: Fri 27 Jun 86 10:04:27-PDT
From: David Singer <DSinger@SRI-KL>
Subject: Re: Argument Lists
To: common-lisp%SU-AI@SRI-KL
A simple proposal is to provide ARGUMENT-LIST, and also
FORM-IS-VALID-CALL i.e. takes the result of ARGUMENT-LIST and a call form
and tells you whether the call form is valid for the given argument list;
a second result might perhaps be a suitable error message if result1 is
false. This would enable user-interface construction tools to check
calls without all a lot of fussing with max, min, keywords, rest etc.
Of course if you really wanted to know what was happening, you could
always have a function which returned an association list showing
how the bindings would go in such a call ...
-------
∂27-Jun-86 1627 KMP@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-MAX-ARGS,etc
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 16:21:55 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 42668; Fri 27-Jun-86 19:19:45 EDT
Date: Fri, 27 Jun 86 19:19 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: FUNCTION-MAX-ARGS,etc
To: Moon@SCRC-STONY-BROOK.ARPA
cc: COMMON-LISP@SU-AI
In-Reply-To: <860627181505.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860627191955.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
MACSYMA would probably want to use FUNCTION-MIN-ARGS, etc. inside its
equivalent of EVAL and/or APPLY. A function which returns all possible
information from one function might be excess overhead in that situation.
I really like the idea of separate functions. We moved away from
the Maclisp ARRAYDIMS which returned type+dim information and provided
separate functions to get the type, dimensions list, individual dimensions,
etc for arrays for what I believe are analogous reasons.
By the way, anything with &KEY automatically allows arbitrarily many
arguments. Does that simplify things? eg, consider:
(DEFUN FOO (&KEY A) A)
(FOO :A 1 :A 2 :A 3 :A 4 ...)
which is clearly defined on p62 to be legal and to return 1. Keyword
mismatches are, therefore, not in the domain of argument -number- checking,
but rather in the domain of argument -type- checking. I'm not saying that's
what I'd like, but it's hard to see any other interpretation.
∂27-Jun-86 1636 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Error Signalling
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 27 Jun 86 16:36:21 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 31499; Fri 27-Jun-86 15:55:57 EDT
Date: Fri, 27 Jun 86 15:55 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Error Signalling
To: mike%gold-hill-acorn@mit-live-oak.arpa, Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 27 Jun 86 11:20 EDT from mike@ALLEGHENY.SCRC.Symbolics.COM
Message-ID: <860627155542.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Fri, 27 Jun 86 10:20 EST
From: mike@a
Date: Thu, 26 Jun 1986 23:14 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
.....
The question we should address is what we should say about such errors
in the standard for Common Lisp. There are three options:
1. The status quo: each of these things "is an error", but it is
entirely up to the implementor whether and under what circumstances to
detect and signal these errors.
I'd say this is a non-spec. It should be possible for an implementation
to detect ALL errors. To say something is an error, but to not
require the implementation to detect it is to make it impossible for
programmers to debug code (unless you like hex core dumps...)
2. The rigorous solution: For errors of the types described above, it is
REQUIRED that implementations signal an error in interpreted code. It
is also required that these errors be signalled in compiled code unless
(optimize (safety 0)) is in effect at compile time.
As far as I'm concerned, this is the only reasonable position to
take. In general, I think the phrase "is an error" in CLtL should be
interpreted as "signals an error unless action is taken to ignore the
condition through declarations." I don't see any difficulty in implementation
here for Gold Hill.
It "is an error" to do
(let ((array (make-array 5 :element-type '(unsigned-byte 13))))
(setf (aref array 4) (ash 1 15)))
but it would be damn inefficient to REQUIRE all implementations to
support every single possibility. In this case, there are a gazillion
array types, but only a limitted number that can be implemented. In the
symbolics implementation, the above make-array returns an array that is
capable of storing 16 bit "bytes" because we "happen" to have an array
type that stores such things with less overhead than a general
can-hold-anything array.
I think changing "is an error" in all cases to "signals an error" would
violate the /Portability/ motivation on page 1 of the Silver Bible.
I think we (or the standards committee) have to carefully at all the "is
an error" and decide if it should be "signals an error". Many of us
agree number of argument checking should be signalled unless safety is
completely turned off, and that even then implementations are encouraged
to check.
3. Sitting on the fence: The conditions stated in option 2 are not
required in the spec, but they are "recommended".
We will soon need to make a formal decision about what goes into the
spec. I'd like to know what people think of these three options --
please try to be brief. Also, if you represent an implementation group,
please indicate whether the requirement in option 1 would make real
I assume you mean option 2.
trouble for you, regardless of whether you favor it. The question is
not whether you could install this by next Tuesday, but whether it would
be a problem to meet this tightened requirement in a release nine months
or a year from now.
-- Scott
...mike beckerle
Gold Hill Computers
∂27-Jun-86 1639 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument lists: a proposal to shoot at
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 27 Jun 86 16:38:45 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 31541; Fri 27-Jun-86 16:10:38 EDT
Date: Fri, 27 Jun 86 16:10 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Argument lists: a proposal to shoot at
To: Guy Steele <gls@Think.COM>, common-lisp@SU-AI.ARPA
In-Reply-To: <860626123445.9.GLS@BOETHIUS.THINK.COM>
Message-ID: <860627161029.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 26 Jun 86 12:34 EDT
From: Guy Steele <gls@Think.COM>
In the following function descriptions, assume that the argument
function has Q required parameters and P &optional parameters, and that
R, K, or A is true iff the function has respectively a &rest, &key, or
&allow-other-keys lambda-keyword.
...
Point of design philosophy: &aux "parameters" aren't anybody's business
at this level of abstraction. I don't deny that for the sake of
debuggers this information, and such other information as the names of
parameters, may be desired.
Other ideas for consideration:
I think the max number of parameters before the &rest is useful.
Why not one function that returns just about everything as multiple
values? Something like
(values min-required-args
max-spead-args
takes-rest-arg-p
takes-keywords-p
allows-other-keywords-p)
Consider a system that allows the programmer to override the argument
list with a declaration, such as
(defun foo (a b &rest c)
(declare (arglist symbol indicator &key package value &allow-other-keys))
...)
Do these functions return what the function really wants or what the
user says it wants?
Consider the case
(defun make-raster-array (width height &rest make-array-keywords
&key &allow-other-keys)
(apply #'make-array (list height width make-array-keywords)))
Here, there are keywords accepted, but it isn't really clear which ones,
since this is an abstraction on top of make-array. [I don't have a good
answer to this one.]
∂27-Jun-86 1705 FAHLMAN@C.CS.CMU.EDU Error Signalling
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jun 86 17:05:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 27 Jun 86 20:04:23-EDT
Date: Fri, 27 Jun 1986 20:04 EDT
Message-ID: <FAHLMAN.12218270483.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Error Signalling
In-reply-to: Msg of 27 Jun 1986 15:55-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
I think changing "is an error" in all cases to "signals an error" would
violate the /Portability/ motivation on page 1 of the Silver Bible.
I think we (or the standards committee) have to carefully at all the "is
an error" and decide if it should be "signals an error". Many of us
agree number of argument checking should be signalled unless safety is
completely turned off, and that even then implementations are encouraged
to check.
Please, let's not go running off on a tangent. I was not suggesting
that EVERY case of "is an error" be changed to "signals an error". I
was merely asking whether people thought that cases like the ones I
enumerated (arg count checking, arg type checking for certain built-in
functions, and array bounds checking) should be tightened up. After
we've decided how to handle these cases in general we can start
discussing which errors are so hard to check that they should be exempt
from the signalling requirement.
-- Scott
∂27-Jun-86 1733 DCP@QUABBIN.SCRC.Symbolics.COM Error Signalling
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 17:32:57 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14433; Fri 27-Jun-86 20:31:35 EDT
Date: Fri, 27 Jun 86 20:31 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Error Signalling
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12218270483.BABYL@C.CS.CMU.EDU>
Message-ID: <860627203125.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Fri, 27 Jun 1986 20:04 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think changing "is an error" in all cases to "signals an error" would
violate the /Portability/ motivation on page 1 of the Silver Bible.
I think we (or the standards committee) have to carefully at all the "is
an error" and decide if it should be "signals an error". Many of us
agree number of argument checking should be signalled unless safety is
completely turned off, and that even then implementations are encouraged
to check.
Please, let's not go running off on a tangent. I was not suggesting
that EVERY case of "is an error" be changed to "signals an error". I
was merely asking whether people thought that cases like the ones I
enumerated (arg count checking, arg type checking for certain built-in
functions, and array bounds checking) should be tightened up.
Sorry. Yes for all three of those, unless safety is turned completely
off, and even then implementations are encouraged to be safe if
possible.
After
we've decided how to handle these cases in general we can start
discussing which errors are so hard to check that they should be exempt
from the signalling requirement.
-- Scott
∂27-Jun-86 1734 DCP@QUABBIN.SCRC.Symbolics.COM Error Signalling
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 17:33:54 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14434; Fri 27-Jun-86 20:31:57 EDT
Date: Fri, 27 Jun 86 20:31 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Error Signalling
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12218270483.BABYL@C.CS.CMU.EDU>
Supersedes: <860627203125.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860627203148.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Fri, 27 Jun 1986 20:04 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think changing "is an error" in all cases to "signals an error" would
violate the /Portability/ motivation on page 1 of the Silver Bible.
I think we (or the standards committee) have to carefully at all the "is
an error" and decide if it should be "signals an error". Many of us
agree number of argument checking should be signalled unless safety is
completely turned off, and that even then implementations are encouraged
to check.
Please, let's not go running off on a tangent. I was not suggesting
that EVERY case of "is an error" be changed to "signals an error". I
was merely asking whether people thought that cases like the ones I
enumerated (arg count checking, arg type checking for certain built-in
functions, and array bounds checking) should be tightened up.
Sorry. Yes for all three of those, unless safety is turned completely
off, and even then implementations are encouraged to be safe if
possible.
After
we've decided how to handle these cases in general we can start
discussing which errors are so hard to check that they should be exempt
from the signalling requirement.
Sounds fair.
-- Scott
-- Not Scott
∂28-Jun-86 1531 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA DRIBBLE
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 28 Jun 86 15:31:15 PDT
Received: from utokyo-relay by csnet-relay.csnet id ad29627; 28 Jun 86 18:30 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA07604; Sat, 28 Jun 86 15:16:56+0900
From: yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA
Received: by nttlab.ntt.junet (4.12/5.0) with TCP; Sat, 28 Jun 86 13:31:09 jst
Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet)
id AA00258; Sat, 28 Jun 86 12:01:01+0900
Date: Sat, 28 Jun 86 12:01:01+0900
Message-Id: <8606280301.AA00258@kurims.kurims.kyoto-u.junet>
To: common-lisp%su-ai.arpa%u-tokyo.junet@CSNET-RELAY.ARPA
Subject: DRIBBLE
Some people detected that DRIBBLE in KCL works quite differently from
other, American Common Lisp systems. The differences certainly came
from the incomplete description of DRIBBLE (page 443). While other
debugging tools depend highly on implementatins, DRIBBLE could be given
more detailed definition independent of the implementation. Here are my
inquiries which, I think, should be made clear.
1. Is it an error to turn DRIBBLE on, while it is on already?
If it is allowed, then what action should the system take? Especially,
"which DRIBBLE" should (DRIBBLE) turn off?
2. Does (DRIBBLE <pathname>) supercede the specified file if it exists
already? Or, does it append? Do you need any additional parameter to
specify this?
3. Which stream variables should (DRIBBLE <pathname>) rebind? CLtL says
only that (DRIBBLE <pathname>) rebinds *STANDARD-INPUT* and *STANDARD-OUTPUT*.
What about other variables such as *TERMINAL-IO* ?
4. Suppose that (DRIBBLE <pathname>) rebinds *STANDARD-INPUT*. Are the
followings are legal uses of DRIBBLE? If legal, what actions should the
system take?
4a.
>(dribble "foo.log")
>(let ((*standard-input* ...))
....
(dribble)
....)
4b.
>(let ((*standard-input* ...))
...
(dribble "foo.log")
...)
>(dribble)
Note: Currently, KCL causes an error in the case of 4a. This is because,
at the exit from the LET form, *STANDARD-OUTPUT* is rebound to a broadcast
stream that includes an already closed stream to foo.log.
-- Taiichi
∂28-Jun-86 2100 LOOSEMORE@UTAH-20.ARPA Re: portability of pathnames
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 28 Jun 86 21:00:19 PDT
Date: Sat 28 Jun 86 21:58:43-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Re: portability of pathnames
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12216964464.BABYL@C.CS.CMU.EDU>
Message-ID: <12218575298.7.LOOSEMORE@UTAH-20.ARPA>
I'm afraid I don't have a real good proposal to offer on this issue, other
than to describe how we have tackled the issue in PCLS, which currently
handles VMS and Unix file systems and has hooks for a few others. Basically,
we view the pathname as consisting of a "place" (the host, device, and
directory), a name, and a type, and don't do too much with versions. There
are consistent conventions for the name and type on all machines; ie, you
can pass lowercase strings with no delimiters to make-pathname and get
something reasonable. (If there are characters in the strings which are
invalid for that particular file system, some appropriate kind of
translation usually occurs automagically.) The specification of the
"place" parts of the pathname, on the other hand, are machine dependent.
Although the hooks are there to support it, we never pass "place"
components to make-pathname in portable code. Instead, we use
merge-pathnames. (We generally only worry about this when we are trying to
find a library file, and in that case the namestring for the "place" is
stored in a global variable; "places" are usually installation-specific
anyway.)
There really seem to be only three situations that probably cover about 95%
of the cases where you want to muck with pathnames:
(1) The user has supplied a complete file name as a string and you want to
find that file.
(2) You are looking for a file with a given name and type in one of several
possible places -- often the default place.
(3) You have somehow acquired a complete pathname and you want to find a
file in the same place with the same name, but with a different extension.
(Like creating a FOO.BIN file in the same place that you found the
corresponding FOO.LISP.)
I would be very happy to see the standard firmed up just enough so that you
can do these three operations in a portable manner. At the very least, the
manual should make clear what operations are guaranteed to work on all
implementations and which are implementation-specific extensions.
-Sandra
-------
∂29-Jun-86 0846 griss%hplmlg@hplabs.HP.COM Re: Argument lists: a proposal to shoot at
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 29 Jun 86 08:46:30 PDT
Received: from hplmlg by hplabs.HP.COM ; Sun, 29 Jun 86 08:44:59 pdt
Received: by hplmlg ; Sun, 29 Jun 86 08:44:43 pdt
From: Martin Griss <griss%hplmlg@hplabs.HP.COM>
Message-Id: <8606291544.AA02251@hplmlg>
Date: Sunday, June 29, 1986 08:44:39
Subject: Re: Argument lists: a proposal to shoot at
To: DCP@QUABBIN.SCRC.Symbolics.COM
Cc: GRISS%hplmlg@hplabs.HP.COM, common-lisp@su-ai.ARPA
In-Reply-To: Your message of 27-Jun-86 16:10:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
I am in favor of DCP's suggested use of multiple-values returned
to return a number of the useful values. Perhaps the first argument or
two could be the most "useful". I also think we may also need another
function, or this function with a keyword argument to get the names of
the keyword parameters.
Martin
-------
∂29-Jun-86 1058 Masinter.pa@Xerox.COM
Received: from XEROX.COM by SU-AI.ARPA with TCP; 29 Jun 86 10:57:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 JUN 86 10:02:31 PDT
Date: 26 Jun 86 15:36 PDT
From: Masinter.pa@Xerox.COM
To: common-lisp@su-ai.ARPA
Message-ID: <860629-100231-1314@Xerox>
Sounds like I wasn't clear enough.
When I suggested portable programs "stick within the set of standard
characters" I was referring to "the Common Lisp character set" as
defined on pp 20-21 of "Common Lisp the Language" by Guy L. Steele Jr.
as follows:
"The Common Lisp character set consists of a space character #\Space, a
newline character #\Newline, and the following ninety-four non-blank
printing characters or their equivalents..."
It looks awfully specific to me, and I'm not sure what our friends at
IBM or Japan would be chuckling about.
In reply to KMPs other points:
"It's important to distinguish between implementation dependent behavior
and unpredictable behavior. Many things in Common Lisp are conceptually
well-defined even though they vary from implementation to
implementation. For example, the behavior of (1+ MOST-POSITIVE-FIXNUM)
varies in detail from implementation to implementation, but
conceptually it does not. I don't think that it's inappropriate to
describe a program as having useful commands bound to keys and to tell
the user to type "?" to see a list of the commands available."
I agree whole-heartedly with this analysis and the appropriateness of
the situation you describe.
"The issue is much bigger than you make it out to be and if you claim it
to be fatal, then I claim you're attacking the whole notion of whether
CL can be portable..."
I object to your claim: I firmly believe that CL can be portable and I'm
making no such attack. That's the point of this whole discussion. I
think that this is in fact one of the few intrinsicly non-portable parts
of the language.
I agree that CHAR-BITS-LIMIT is in the same class as
"MOST-POSITIVE-FIXNUM". The issue as I see it is: does this abstraction
*encourage* or *discourage* users from writing portable programs?
I claim that this particular feature works against portability: It is my
belief that having "char-bits" in the book will encourage users who are
working in an implementation which supports "char-bits" to rely upon
"char-bits" in their programs, with a nod to the fact "well, those
lusers without char-bits just can't use this program".
If char-bits were *not* in the standard, then the writer of a portable
program would set aside a table somewhere, which said:
; implementation-dependent table of character codes and their functions
#\control-A delete-next-character
#\control-R retype-line
and clearly identify that these were not "standard" (in the sense of pp
20-21) characters. Let me put it in terms of a more definite proposal in
terms of chapter and verse:
a) eliminate constants char-code-limit, char-font-limit and
char-bits-limit, and instead have a constants:
char-integer-limit [Constant]
The value of char-integer-limit is a non-negative integer that is the
upper exclusive bound on values produced by the function char-integer.
...
string-char-integer-limit [constant]
The value of string-char-integer-limit is the upper exclusive bound on
values produced by the funcion char-integer for characters which satisfy
string-char-p.
[Implementation note: older Common Lisps can implement this by
(defconstant char-integer-limit (+ char-code-limit char-font-limit
char-bits-limit))
(defconstant string-char-integer-limit char-code-limit)]
b) change the wording of char-upcase and char-downcase to omit
references to "characters with non-zero bits". [note: I detect an
inconsistency in the description of char-upcase on p. 241, which in the
second paragraph says that it returns a character object with the same
font and bits attributes but with possibly a different code, and in the
last paragraph says that they have no effect on characters with non-zero
bits attributes]
c) eliminate functions char-code, char-bits, char-font, code-char,
make-char from the standard.
[Compatibility note: users with older common lisp programs may want to
define char-code as (mod (char-int char) string-char-integer-limit)) and
similarly make the other ones as transforms on char-integers]
d) eliminate the constants char-control-bit char-meta-bit char-super-bit
char-hyper-bit and the functions char-bit set-char-bit. [Compatibility
note: users with older common lisp programs who want to use these
features can define these constants as 1 2 4 8 respectively, and define
(defun char-bit char name
(int-char (logtest (int-char char)
(* string-char-integer-limit (ecase name (:control 1) (:meta 2)
...))))))
∂29-Jun-86 1109 shebs%utah-orion@utah-cs.arpa Re: portability of pathnames
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 11:09:44 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA25027; Sun, 29 Jun 86 12:09:29 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA11953; Sun, 29 Jun 86 12:09:18 MDT
Date: Sun, 29 Jun 86 12:09:18 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8606291809.AA11953@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: portability of pathnames
Summary:
Expires:
References: <[G.BBN.COM]23-Jun-86 11:11:44.NGALL>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
>From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
>I came across your complaint about portability of pathnames and the
>problems with make-pathname. I was just wondering if
>you had anything specific to propose.
I submit there are NO portable things to be done with pathnames.
Even something as innocuous as (load "foo-bar-baz") isn't going to
be portable to machines with only short filenames, or ones that don't
allow hyphens in filenames. Proposals that the implementation can
map names around are bogus, since in the simplest case (changing chars
in the name) things like
(with-open-file (s1 "foo-bar-baz" :direction :output)
(with-open-file (s2 "foo←bar←baz" :direction :output)
...))
will get pretty strange, and in the most complex case, the implementation must
have its own mini-filesystem to conform to the standard. As things
stand now, you can't have a Common Lisp on a machine without a filesystem!
More plausibly, you can't have one where random objects like floating-point
numbers designate files (a la the EZ programming environment).
In the practice of porting programs, I've had to put all explicit filenames
and pathname operations into machine-specific files. Even something like
(merge-pathnames :type "lisp" :defaults "/usr/games/doctor")
is not guaranteed to work on a Unix implementation that decides (correctly)
that Unix files don't really have types.
My proposal: flush all pathname stuff entirely. Pathnames are abstract
objects with no user-visible components. The PATHNAME function still exists
to coerce other kinds of objects (probably strings) into pathnames; OPEN
and other operations need not look any different. TRUENAME is probably
still worthwhile, but none of the others are truly portable, so there's
little point in standardizing on them. Implementations can provide whatever
ones are appropriate.
There's a certain analogy with character bits and fonts, the main difference
being that more people feel compelled to do *something* with pathnames.
The standard is so full of loopholes that once one gets outside the realm
of vanilla Unix/VMS/Tops-20 filenames, any pathname manipulation is just
not going to work right. So let's shrink the standard and not exercise
ourselves trying to design a filesystem interface that will accommodate
every strangeness invented by the OS people.
stan
∂29-Jun-86 1117 shebs%utah-orion@utah-cs.arpa Re: portability of pathnames
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 11:17:05 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA25203; Sun, 29 Jun 86 12:16:22 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA12008; Sun, 29 Jun 86 12:16:11 MDT
Date: Sun, 29 Jun 86 12:16:11 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8606291816.AA12008@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: portability of pathnames
Summary:
Expires:
References: <860623211400.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <860623211400.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Moon@STONY-BROOK.SCRC.Symbolics.COM (David A. Moon) writes:
>Get your hands on a Symbolics document set and read about Logical
>Pathnames. If I understand your requirements, Logical Pathnames are
>exactly what you're looking for.
Logical pathnames are good in that they can be machine-independent.
However, it seemed to me that they amounted to building a mini-filesystem
within Common Lisp, and we have enough problems compromising on a basic
language without trying to standardize on the operating system too!
stan
∂29-Jun-86 1124 shebs%utah-orion@utah-cs.arpa Re: Argument Lists
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 11:23:20 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA25310; Sun, 29 Jun 86 12:22:58 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA12060; Sun, 29 Jun 86 12:22:47 MDT
Date: Sun, 29 Jun 86 12:22:47 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8606291822.AA12060@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: Argument Lists
Summary:
Expires:
References: <FAHLMAN.12217236274.BABYL@C.CS.CMU.EDU>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <FAHLMAN.12217236274.BABYL@C.CS.CMU.EDU> Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) writes:
>
> It is not required that an
> implementation signal an error when there are either too many or too few
> arguments...
>
>I would have sworn that implementaitosn were required to signal an error
>in this case, but a scan of CLtL seems to indicate that you are right.
>The section on argument lists consistently says "is an error" and not
>"signals an error". I can't remember (or imagine) why these cases
>aren't required to signal an error, and I think this should be fixed.
I thought the reason was that implementations shouldn't be required to
do *any* checking as a part of function-calling protocol, since it would
slow things down on stock hardware.
>Does anyone disagree?
It's fine as it stands. Error checking should be optional, except in the
most infrequent or potentially catastrophic situations (i.e. package system).
>Are there any implementations out there that
>don't signal errors when a function is given too many or too few args?
PCLS is pretty sleazy most of the time... people seem to like it that way :-)
>-- Scott
stan
∂29-Jun-86 1150 shebs%utah-orion@utah-cs.arpa Re: Error Signalling
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 11:49:56 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA25909; Sun, 29 Jun 86 12:49:40 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA12165; Sun, 29 Jun 86 12:49:29 MDT
Date: Sun, 29 Jun 86 12:49:29 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8606291849.AA12165@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: Error Signalling
Summary:
Expires:
References: <FAHLMAN.12218043005.BABYL@C.CS.CMU.EDU>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <FAHLMAN.12218043005.BABYL@C.CS.CMU.EDU> Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) writes:
>2. The rigorous solution: For errors of the types described above, it is
>REQUIRED that implementations signal an error in interpreted code. It
>is also required that these errors be signalled in compiled code unless
>(optimize (safety 0)) is in effect at compile time.
This would be good - I bet a lot of system code would benefit from the
scrutiny necessary to fix this up. Will increase size of implementations,
especially those that need to have two versions of function (safe one calls
unsafe one, of course, but still some overhead I think).
BTW, why not flush the silly numbers and use t,nil or else keyword names
like :unsafe and :bombproof and :nuclear-qualified? 0s and 3s don't
convey much meaning....
stan
∂29-Jun-86 1154 Bobrow.pa@Xerox.COM Re: portability of pathnames
Received: from XEROX.COM by SU-AI.ARPA with TCP; 29 Jun 86 11:54:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 JUN 86 11:37:35 PDT
Date: 27 Jun 86 18:25 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: portability of pathnames
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 23 Jun 86 21:14 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA
From: Bobrow.pa@Xerox.COM (Danny Bobrow)
Message-ID: <860629-113735-2153@Xerox>
I have been looking at the documentation for logical path names and have
been impressed by their utility. We had been trying to reinvent
something with the similar properties for other purposes. I do not yet
understand them well, but I think logical path names might fill much of
the need expressed. We should look at them for Common Lisp.
-- danny
∂29-Jun-86 1231 FAHLMAN@C.CS.CMU.EDU Error Signalling
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Jun 86 12:31:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 29 Jun 86 15:31:43-EDT
Date: Sun, 29 Jun 1986 15:31 EDT
Message-ID: <FAHLMAN.12218745136.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Error Signalling
In reply to: shebs at utah-orion.UUCP (Stanley Shebs)
Regarding your comment that PCLS is "pretty sleazy most of the time"
with respect to argument checking and that "users seem to like it that
way", it would of course be allowable for any self-proclaimed subset not
to do this checking. Whether that's among the ways in which you would
want to deviate from the standard is another question, but it's one for
your group to decide internally, since you have declared that you don't
intend to implement the full standard. (Or am I misunderstanding the
goals of PCLS?)
Anyway, in your later note you seem to agree that requiring this
checking in the standard, except where the user has indicated that
safety is not important, is OK with you, so I guess we have no
disagreement.
BTW, why not flush the silly numbers and use t,nil or else keyword names
like :unsafe and :bombproof and :nuclear-qualified? 0s and 3s don't
convey much meaning....
The thought was that the user might want to convey more information
about his preferences than would be possible in using binary-valued
switches. A limited range of numbers seemed like the most reasonable
and least confusing solution, though it's clearly not ideal. A number
of the more complex CLisp implementations make good use of the
multiplicity of values to fine-tune which optimizations their compiler
employs.
-- Scott
∂29-Jun-86 1620 LOOSEMORE@UTAH-20.ARPA Error signalling
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 16:20:17 PDT
Date: Sun 29 Jun 86 17:18:50-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Error signalling
To: common-lisp@SU-AI.ARPA
Message-ID: <12218786489.6.LOOSEMORE@UTAH-20.ARPA>
Let me get this straight: what is being proposed is that when *user*
code is compiled with safety=0, *system* functions are allowed to bypass
error checking? Presumably one would have to implement this by having
two sets of system functions, the default one that does the error checks
and another one that doesn't, and make the compiler smart enough to
make the substitution when appropriate. Bleah -- I can see doing this
manually for a few functions, but trying to cover all the places where
CLtL says "it is an error" seems like a royal pain. If this is adopted
as part of the standard, I'd also like to see some mechanisms to help
automate the implementation provided. I think "user" code could also
make good use of the same hooks for optional error checking.
A minor point -- why restrict error checking to all-or-nothing? Some
assumptions about argument values may be "safer" than others. If you set
safety=3 you probably want to be extra paranoid and do *more* error
checking than the default. In other words, the error checks should be
qualified with a safety setting....
-Sandra
-------
∂29-Jun-86 1710 shebs%utah-orion@utah-cs.arpa Re: Error Signalling
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 17:09:59 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA28711; Sun, 29 Jun 86 18:09:44 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA12645; Sun, 29 Jun 86 18:09:30 MDT
Date: Sun, 29 Jun 86 18:09:30 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8606300009.AA12645@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: Error Signalling
Summary:
Expires:
References: <FAHLMAN.12218745136.BABYL@C.CS.CMU.EDU>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <FAHLMAN.12218745136.BABYL@C.CS.CMU.EDU> Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) writes:
>
>Or am I misunderstanding the goals of PCLS?
We're not going to live with it forever, it's just a hack so we can
learn CL implementation and figure out the right way to do a full CL.
We've waffled about error checking and cringed at the storage overhead of #2,
even though it's probably the best choice.
>The thought was that the user might want to convey more information
>about his preferences than would be possible in using binary-valued
>switches. A limited range of numbers seemed like the most reasonable
>and least confusing solution, though it's clearly not ideal. A number
>of the more complex CLisp implementations make good use of the
>multiplicity of values to fine-tune which optimizations their compiler
>employs.
It's *probably* not a portability problem that (safety 1) means something
different in different implementations. PCLS uses the speed settings to
switch various kinds of optimizations, but we didn't have much intuition
about what the difference between (speed 2) and (speed 3) should be, and
it seemed that users who were picky about those things were just as likely
to want to know about PCLS's compiler flags that controlled each sort of
optimization. No big deal, I guess.
>-- Scott
stan
∂29-Jun-86 1954 franz!fizzy!jkf@kim.Berkeley.EDU Re: Error Signalling
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 29 Jun 86 19:54:45 PDT
Received: by kim.Berkeley.EDU (5.51/1.14)
id AA24458; Sun, 29 Jun 86 18:50:22 PDT
From: franz!fizzy!jkf@kim.Berkeley.EDU
Received: from fizzy by franz (5.5/3.14)
id AA08721; Sun, 29 Jun 86 18:18:01 PDT
Received: by fizzy (4.12/3.14)
id AA04052; Sun, 29 Jun 86 18:18:24 pdt
Return-Path: <fizzy!jkf>
Message-Id: <8606300118.AA04052@fizzy>
To: ucbkim!utah-cs.arpa!shebs (Stanley Shebs)
Cc: common-lisp@su-ai.arpa
Subject: Re: Error Signalling
In-Reply-To: Your message of Sun, 29 Jun 86 18:09:30 MST.
<8606300009.AA12645@utah-orion.ARPA>
Date: Sun, 29 Jun 86 18:18:21 PDT
>> It's *probably* not a portability problem that (safety 1) means something
>> different in different implementations. PCLS uses the speed settings to
>> switch various kinds of optimizations, but we didn't have much intuition
>> about what the difference between (speed 2) and (speed 3) should be
>> ...
We also didn't know what should be done for the various settings of
speed, size and safety so we put the decision back in the users'
hands.
Our compiler can perform a number of optimizations, some of the
optimizations involve removing safety checks and for these we felt
that the user should be aware of what they are and should have control
over when they are done.
Therefore each optimization is controlled by a function of safety,
size and speed. The user is free to redefine the functions if he
doesn't like the default function. Here is an example of the function
which controls one of the optimizations discussed recently: that of
not checking the number of arguments passed to the function:
(defvar verify-argument-count-switch
#'(lambda (safety size speed)
(declare (ignore size))
(or (< speed 3)
(> safety 0)))
"bound to a function which given safety, size and speed returns t
if the compiler should generate code to verify that the correct number
of arguments were passed to a function.
Note: an argument count check is always done if there are optional
or rest arguments.")
-john foderaro
Franz Inc.
∂29-Jun-86 1959 FAHLMAN@C.CS.CMU.EDU Error signalling
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Jun 86 19:59:14 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 29 Jun 86 22:29:52-EDT
Date: Sun, 29 Jun 1986 20:59 EDT
Message-ID: <FAHLMAN.12218804888.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Error signalling
Let me get this straight: what is being proposed is that when *user*
code is compiled with safety=0, *system* functions are allowed to bypass
error checking? Presumably one would have to implement this by having
two sets of system functions, the default one that does the error checks
and another one that doesn't, and make the compiler smart enough to
make the substitution when appropriate. Bleah -- I can see doing this
manually for a few functions, but trying to cover all the places where
CLtL says "it is an error" seems like a royal pain. If this is adopted
as part of the standard, I'd also like to see some mechanisms to help
automate the implementation provided. I think "user" code could also
make good use of the same hooks for optional error checking.
First, to repeat what I said earlier, nobody is proposing that all "it
is an error" cases come under this rule. The question was whether we
want to do this for three important classes of errors, perhaps creating
a precedent for the handling of other things.
Second, the cases in question are typically those that are open-coded by
the compiler. Everyone agrees that, other things being equal, CDR
should check that its argument is a list, SVREF should check for an
out-of bounds reference, and function calls should check that the number
of arguments is legal. But when these things are open-coded, the
cost of these tests might slow things down by a factor of 2 or more.
That is why the manual does not currently require that an error be
signalled in such cases. The suggestion is that we require every
implementation to provide the safe version to users who ask for safety;
if user code is compiled with safety = 0, the compiler may (but is not
required to) omit the runtime checks in favor of greater speed.
My guess is that most implementations will choose to provide only one
version of built-in system functions, and that these versions will be
safe in the necessary ways. Basically, this would mean that the built
in functions do not contain any errors and that they subject the user's
arguments to the appropriate scrutiny to make sure that they are legal.
It would be allowable to provide a second, quick-and-dirty version that
is called by user code compiled when safety = 0, but in most cases the
savings would so small that implmentors would not bother to do this. It
is always legal to have more safety than is required.
A minor point -- why restrict error checking to all-or-nothing? Some
assumptions about argument values may be "safer" than others. If you set
safety=3 you probably want to be extra paranoid and do *more* error
checking than the default. In other words, the error checks should be
qualified with a safety setting....
I am not suggesting that we restrict error checking to all-or-nothing.
The suggestion was that these particular checks should kick in whenever
safety is greater than 0, but the important issue is whether we require
these checks to be available at SOME level of safety. Currently this is
completely at the discretion of the implementor.
-- Scott
∂29-Jun-86 1959 FAHLMAN@C.CS.CMU.EDU DRIBBLE
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Jun 86 19:59:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 29 Jun 86 22:29:53-EDT
Date: Sun, 29 Jun 1986 21:47 EDT
Message-ID: <FAHLMAN.12218813480.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: DRIBBLE
In-reply-to: Msg of Sat 28 Jun 86 12:01:01+0900 from yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet at CSNET-RELAY.ARPA
In reply to Yuasa%kurims....
DRIBBLE is deliberately under-specified. The intention is that
(DRIBBLE <pathname>)
should save a record of the terminal interaction in the specified file.
Exactly how to do that, for maximum user convenience, is something that
will vary considerably from one system to another. We didn't want to
get into the business of specifying exactly how this should be done.
I have hesitated to respond to your questions because I never use
DRIBBLE myself. In Spice Lisp we have a DRIBBLE, but we almost always
use Hemlock as an editor top-level, so DRIBBLE is useless -- if we want
to save a transcript of the current terminal session, we just write the
top-level buffer to a file. I suspect that editor top-levels will
become more popular as time goes on, and that DRIBBLE will gradually
wither away until it is a curious relic of ancient times, when people
typed directly to Lisp listeners.
But since no one else has stepped forward, let me offer some opinions on
what is tasteful. Almost anything is legal.
1. I think that calling DRIBBLE while DRIBBLE is already in effect is an
error. It is probably best to warn the user in this case and to ignore
the redundant call.
2. I suspect that most people would expect DRIBBLE to supersede any
older file with the same name, though such expectations depend on the
usual conventions of the operating system in question. It might be a
useful option to append to the old file, but you don't want to surprise
your users with this action. Maybe there should be a DRIBBLE-APPEND
function to provide this functionality.
3. I think that in most cases, rebinding *STANDARD-INPUT* and
*STANDARD-OUTPUT* does the job. Why would you want to rebind
*TERMINAL-IO* ?
4. If you accept my suggestion that recursive calls to DRIBBLE be
treated as errors, 4a is illegal. To handle cases like 4b properly,
DRIBBLE will need to rebind *STANDARD-INPUT* and *STANDARD-OUTPUT* to
a broadcast stream that includes the current values plus the file that
is to hold the dribbled output. There is probably no way to win (and
certainly no way that is worth the trouble) if the user insists on
messing around with *STANDARD-INPUT* and *STANDARD-OUTPUT* himself while
the DRIBBLE is in effect.
-- Scott
∂29-Jun-86 2201 NGALL@G.BBN.COM Re: DRIBBLE
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 22:01:26 PDT
Date: 30 Jun 1986 01:00-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: DRIBBLE
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]30-Jun-86 01:00:31.NGALL>
In-Reply-To: <FAHLMAN.12218813480.BABYL@C.CS.CMU.EDU>
Date: Sun, 29 Jun 1986 21:47 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Subject: DRIBBLE
In reply to Yuasa%kurims....
DRIBBLE is deliberately under-specified. The intention is that
(DRIBBLE <pathname>)
should save a record of the terminal interaction in the specified file.
Exactly how to do that, for maximum user convenience, is something that
will vary considerably from one system to another. We didn't want to
get into the business of specifying exactly how this should be done.
There's a big difference between "specifying exactly how this should
be done" and standardizing on the basic behavior that Taiichi
questions below. Also, I don't buy the line that "exactly how to do
that, for maximum user convenience, is something that will vary
considerably from one system to another". If DRIBBLE is going to
behave so radically differently in different CLs, then the user has no
real idea what will happen when s/he types (DRIBBLE ...) or (DRIBBLE).
And if that's the case, we may as well flush it from CLtL. Also, if a
particular CL has such considerably different views from the basic
DRIBBLE spec., then it can always use keywords, specials, or make up a
new function to get the different behavior. The truth is (I think),
most CLs have implemented DRIBBLE along the lines you suggest, so why
not capitalize on this de facto standard and set down the "basic"
behavior of DRIBBLE.
I find dribble extremely useful in four CLs that do not have
editor-transcript buffers, so I would like to see DRIBBLE standardized
enough to feel safe in using it on any new CL I go to. Standardizing
on answers to the questions below would go a long way towards that.
1. I think that calling DRIBBLE while DRIBBLE is already in effect is an
error. It is probably best to warn the user in this case and to ignore
the redundant call.
I would prefer if the standard said "signals an error".
2. I suspect that most people would expect DRIBBLE to supersede any
older file with the same name, though such expectations depend on the
usual conventions of the operating system in question. It might be a
useful option to append to the old file, but you don't want to surprise
your users with this action. Maybe there should be a DRIBBLE-APPEND
function to provide this functionality.
Agreed. Perhaps a keyword analogous to OPENs :if-exists.
3. I think that in most cases, rebinding *STANDARD-INPUT* and
*STANDARD-OUTPUT* does the job. Why would you want to rebind
*TERMINAL-IO* ?
We use dribble to record system compiles and load-ups. How do we get
error messages, trace-output, etc., in our dribble file?
*STANDARD-INPUT* and *STANDARD-OUTPUT* represent only part of the
system's "interactive session"; *TERMINAL-IO* would capture all of it
(in most implementations).
4. If you accept my suggestion that recursive calls to DRIBBLE be
treated as errors, 4a is illegal. To handle cases like 4b properly,
DRIBBLE will need to rebind *STANDARD-INPUT* and *STANDARD-OUTPUT* to
a broadcast stream that includes the current values plus the file that
is to hold the dribbled output. There is probably no way to win (and
certainly no way that is worth the trouble) if the user insists on
messing around with *STANDARD-INPUT* and *STANDARD-OUTPUT* himself while
the DRIBBLE is in effect.
Another argument in favor of using *TERMIAL-IO*, since the user is
warned not to touch it.
As it stands currently, there is no defined way to ensure that no
dribbling is being done. Doing (DRIBBLE) when there is no dribbling
may cause an error in some systems. I suggest that (DRIBBLE) be legal
at any time, and that it return NIL if there was no dribbling in
progress, and the truename of the file being dribbled to if it was
dribbling.
-- Nick
∂29-Jun-86 2235 NGALL@G.BBN.COM Re: Argument lists: a proposal to shoot at
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 22:35:45 PDT
Date: 30 Jun 1986 01:35-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Argument lists: a proposal to shoot at
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]30-Jun-86 01:35:20.NGALL>
In-Reply-To: <FAHLMAN.12218049604.BABYL@C.CS.CMU.EDU>
Date: Thu, 26 Jun 1986 23:51 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Subject: Argument lists: a proposal to shoot at
In-Reply-To: Msg of 26 Jun 1986 19:17-EDT from NGALL at G.BBN.COM
Message-ID: <FAHLMAN.12218049604.BABYL@C.CS.CMU.EDU>
Your encoding scheme does not let me see the number of
'probably-stack-based' parameters (i.e., P+Q) given a function that
has a &rest param and no &key params. This makes it impossible to
provide an encapsulation that would use &rest only where necessary (it
would force the use of a &rest parameter for all args beyond the
required parameters).
Sorry, maybe I'm being dense, but I don't understand this. What is it
that an encapsulation can do better if it can see P+Q ? Why do you want
to rip the lid off this particular black box?
-- Scott
What follows is some code that demonstrates what I had in mind. The
function ENCAPPED is the function that my encapsulation program has to
put a wrapper around. ENCAP1 is an example of the kind of wrapper
that is possible when both Q and P are known. ENCAP2 is an example of
the kind of wrapper that must be used when only Q is known. (I am
ignore the issue of keywords here.)
(defvar *defaulted-optional-marker* (make-symbol "DEFAULTED-OPTIONAL-MARKER"))
(defun encap1 (r1 r2 &optional (o1 *defaulted-optional-marker*)
(o2 *defaulted-optional-marker*)
(o3 *defaulted-optional-marker*)
&rest rest)
(declare (optimize (speed 3) (safety 0) (space 0)))
(prog2
t ;; (before)
(cond ((eq o1 *defaulted-optional-marker*)
(encapped r1 r2))
((eq o2 *defaulted-optional-marker*)
(encapped r1 r2 o1))
((eq o3 *defaulted-optional-marker*)
(encapped r1 r2 o1 o2))
((null rest)
(encapped r1 r2 o1 o2 o3))
(t (apply #'encapped r1 r2 o1 o2 o3 rest)))
;; (after)
))
(defun encap2 (r1 r2 &rest rest)
(declare (optimize (speed 3) (safety 0) (space 0)))
(prog2
t ;; (before)
(apply #'encapped r1 r2 rest)
;; (after)
))
(defun encapped (r1 r2 &optional (o1 1) (o2 2) (o3 3) &rest rest)
(setf foor1 r1)
(setf foor2 r2)
(setf fooo1 o1)
(setf fooo2 o2)
(setf fooo3 o3)
(setf foorest rest))
(defun tencap1 (n)
(time (dotimes (i n) (encap1 'a 'b 'c 'd 'e))))
(defun tencap2 (n)
(time (dotimes (i n) (encap2 'a 'b 'c 'd 'e))))
Note that ENCAP1 has exactly the same lambda-list-signature as
ENCAPPED.
ENCAP1 benchmarks considerably faster in three CLs that I tried it in
than ENCAP2.
Now it is true that one could always use an arbitrary number of
optionals in the wrapper lambda-list, but one could not be sure that
one had used enough or too many, e.g., if I always use 10 optionals,
the wrapper could slow things down if the encapsulated function never
took more than 3 args. after the requireds.
Its not a big deal, but then neither is returning P.
-- Nick
∂29-Jun-86 2311 NGALL@G.BBN.COM Re: Argument lists: a proposal to shoot at
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 22:35:45 PDT
Date: 30 Jun 1986 01:35-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Argument lists: a proposal to shoot at
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]30-Jun-86 01:35:20.NGALL>
In-Reply-To: <FAHLMAN.12218049604.BABYL@C.CS.CMU.EDU>
Date: Thu, 26 Jun 1986 23:51 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Subject: Argument lists: a proposal to shoot at
In-Reply-To: Msg of 26 Jun 1986 19:17-EDT from NGALL at G.BBN.COM
Message-ID: <FAHLMAN.12218049604.BABYL@C.CS.CMU.EDU>
Your encoding scheme does not let me see the number of
'probably-stack-based' parameters (i.e., P+Q) given a function that
has a &rest param and no &key params. This makes it impossible to
provide an encapsulation that would use &rest only where necessary (it
would force the use of a &rest parameter for all args beyond the
required parameters).
Sorry, maybe I'm being dense, but I don't understand this. What is it
that an encapsulation can do better if it can see P+Q ? Why do you want
to rip the lid off this particular black box?
-- Scott
What follows is some code that demonstrates what I had in mind. The
function ENCAPPED is the function that my encapsulation program has to
put a wrapper around. ENCAP1 is an example of the kind of wrapper
that is possible when both Q and P are known. ENCAP2 is an example of
the kind of wrapper that must be used when only Q is known. (I am
ignore the issue of keywords here.)
(defvar *defaulted-optional-marker* (make-symbol "DEFAULTED-OPTIONAL-MARKER"))
(defun encap1 (r1 r2 &optional (o1 *defaulted-optional-marker*)
(o2 *defaulted-optional-marker*)
(o3 *defaulted-optional-marker*)
&rest rest)
(declare (optimize (speed 3) (safety 0) (space 0)))
(prog2
t ;; (before)
(cond ((eq o1 *defaulted-optional-marker*)
(encapped r1 r2))
((eq o2 *defaulted-optional-marker*)
(encapped r1 r2 o1))
((eq o3 *defaulted-optional-marker*)
(encapped r1 r2 o1 o2))
((null rest)
(encapped r1 r2 o1 o2 o3))
(t (apply #'encapped r1 r2 o1 o2 o3 rest)))
;; (after)
))
(defun encap2 (r1 r2 &rest rest)
(declare (optimize (speed 3) (safety 0) (space 0)))
(prog2
t ;; (before)
(apply #'encapped r1 r2 rest)
;; (after)
))
(defun encapped (r1 r2 &optional (o1 1) (o2 2) (o3 3) &rest rest)
(setf foor1 r1)
(setf foor2 r2)
(setf fooo1 o1)
(setf fooo2 o2)
(setf fooo3 o3)
(setf foorest rest))
(defun tencap1 (n)
(time (dotimes (i n) (encap1 'a 'b 'c 'd 'e))))
(defun tencap2 (n)
(time (dotimes (i n) (encap2 'a 'b 'c 'd 'e))))
Note that ENCAP1 has exactly the same lambda-list-signature as
ENCAPPED.
ENCAP1 benchmarks considerably faster in three CLs that I tried it in
than ENCAP2.
Now it is true that one could always use an arbitrary number of
optionals in the wrapper lambda-list, but one could not be sure that
one had used enough or too many, e.g., if I always use 10 optionals,
the wrapper could slow things down if the encapsulated function never
took more than 3 args. after the requireds.
Its not a big deal, but then neither is returning P.
-- Nick
∂30-Jun-86 0619 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: Error Signalling
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 30 Jun 86 06:18:24 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 32238; Mon 30-Jun-86 09:17:12 EDT
Date: Mon, 30 Jun 86 09:17 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Error Signalling
To: franz!fizzy!jkf@kim.Berkeley.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8606300118.AA04052@fizzy>
Message-ID: <860630091710.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sun, 29 Jun 86 18:18:21 PDT
From: franz!fizzy!jkf@kim.Berkeley.EDU
>> It's *probably* not a portability problem that (safety 1) means something
>> different in different implementations. PCLS uses the speed settings to
>> switch various kinds of optimizations, but we didn't have much intuition
>> about what the difference between (speed 2) and (speed 3) should be
>> ...
We also didn't know what should be done for the various settings of
speed, size and safety so we put the decision back in the users'
hands.
Our compiler can perform a number of optimizations, some of the
optimizations involve removing safety checks and for these we felt
that the user should be aware of what they are and should have control
over when they are done.
Therefore each optimization is controlled by a function of safety,
size and speed. The user is free to redefine the functions if he
doesn't like the default function. Here is an example of the function
which controls one of the optimizations discussed recently: that of
not checking the number of arguments passed to the function:
(defvar verify-argument-count-switch
#'(lambda (safety size speed)
(declare (ignore size))
(or (< speed 3)
(> safety 0)))
"bound to a function which given safety, size and speed returns t
if the compiler should generate code to verify that the correct number
of arguments were passed to a function.
Note: an argument count check is always done if there are optional
or rest arguments.")
Nit: that isn't in the LISP: or USER: package, I hope, but SYS: or some
other private package.
-john foderaro
Franz Inc.
∂30-Jun-86 0619 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM two functions for everything
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 30 Jun 86 06:16:20 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 32234; Mon 30-Jun-86 09:15:09 EDT
Date: Mon, 30 Jun 86 09:15 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: two functions for everything
To: common-lisp@SU-AI.ARPA
Message-ID: <860630091505.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
This is bogus folks. All you need is two entrypoints: one which doesn't
check anything, and one which checks what it needs to. They then join.
Safety 0 (at compile time) causes functions to call the the
don't-check-anything entrypoint, and safety > 0 causes functions to call
the one that checks. Hell, you could have a different entrypoint for
each setting of safety.
We should be debating implementation issues less and debating what we
want the specification for a robust language to state.
∂30-Jun-86 0751 franz!fizzy!jkf@kim.Berkeley.EDU Re: Error Signalling
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 30 Jun 86 07:51:38 PDT
Received: by kim.Berkeley.EDU (5.51/1.14)
id AA00572; Mon, 30 Jun 86 07:51:45 PDT
From: franz!fizzy!jkf@kim.berkeley.edu
Received: from fizzy by franz (5.5/3.14)
id AA10208; Mon, 30 Jun 86 07:46:22 PDT
Received: by fizzy (4.12/3.14)
id AA05530; Mon, 30 Jun 86 07:46:45 pdt
Return-Path: <fizzy!jkf>
Message-Id: <8606301446.AA05530@fizzy>
To: David C. Plummer <ucbkim!QUABBIN.SCRC.Symbolics.COM!DCP>
Cc: common-lisp@su-ai.arpa
Subject: Re: Error Signalling
In-Reply-To: Your message of Mon, 30 Jun 86 09:17:00 EDT.
<860630091710.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon, 30 Jun 86 07:46:43 PDT
>> Nit: that isn't in the LISP: or USER: package, I hope, but SYS: or some
>> other private package.
Yes, it is in the compiler package. If other implementations use this
idea and want to make it portable, we wouldn't mind moving these
symbols to the a package such as the system package, a private
package which most implementations have.
- john foderaro
Franz Inc.
∂30-Jun-86 0754 LOOSEMORE@UTAH-20.ARPA Two functions for everything?
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 30 Jun 86 07:54:10 PDT
Date: Mon 30 Jun 86 08:52:34-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Two functions for everything?
To: common-lisp@SU-AI.ARPA
Message-ID: <12218956472.19.LOOSEMORE@UTAH-20.ARPA>
From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
This is bogus folks. All you need is two entrypoints: one which doesn't
check anything, and one which checks what it needs to. They then join.
Safety 0 (at compile time) causes functions to call the the
don't-check-anything entrypoint, and safety > 0 causes functions to call
the one that checks. Hell, you could have a different entrypoint for
each setting of safety.
Yeah, but where in CLtL do we provide a way to make functions with multiple
entry points? I certainly don't want to have to hand-code every single
function that does optional error checking in assembly language (or
whatever). The point I was trying to make was that, if we are serious
about making multiple levels of error checking part of the language, we
should also provide some high-level constructs for specifying what error
checking goes on when. Multiple entry points would be one way to implement
such a construct....
-Sandra
-------
∂30-Jun-86 0937 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA DRIBBLE
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 30 Jun 86 09:35:13 PDT
Received: from utokyo-relay by csnet-relay.csnet id ab00802; 30 Jun 86 12:30 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA01657; Mon, 30 Jun 86 21:14:43+0900
From: yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA
Received: by nttlab.ntt.junet (4.12/5.0) with TCP; Mon, 30 Jun 86 13:22:16 jst
Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet)
id AA00372; Mon, 30 Jun 86 11:49:49+0900
Date: Mon, 30 Jun 86 11:49:49+0900
Message-Id: <8606300249.AA00372@kurims.kurims.kyoto-u.junet>
To: Common-Lisp%SU-AI.ARPA%u-tokyo.junet@CSNET-RELAY.ARPA
Subject: DRIBBLE
Some people detected that DRIBBLE in KCL works quite differently from
other, American Common Lisp systems. The differences certainly came
from the incomplete description of DRIBBLE (page 443). While other
debugging tools depend highly on implementatins, DRIBBLE could be given
more detailed definition independent of the implementation. Here are my
inquiries which, I think, should be made clear.
1. Is it an error to turn DRIBBLE on, while it is on already?
If it is allowed, then what action should the system take? Especially,
"which DRIBBLE" should (DRIBBLE) turn off?
2. Does (DRIBBLE <pathname>) supercede the specified file if it exists
already? Or, does it append? Do you need any additional parameter to
specify this?
3. Which stream variables should (DRIBBLE <pathname>) rebind? CLtL says
only that (DRIBBLE <pathname>) rebinds *STANDARD-INPUT* and *STANDARD-OUTPUT*.
What about other variables such as *TERMINAL-IO* ?
4. Suppose that (DRIBBLE <pathname>) rebinds *STANDARD-INPUT*. Are the
followings are legal uses of DRIBBLE? If legal, what actions should the
system take?
4a.
>(dribble "foo.log")
>(let ((*standard-input* ...))
....
(dribble)
....)
4b.
>(let ((*standard-input* ...))
...
(dribble "foo.log")
...)
>(dribble)
Note: Currently, KCL causes an error in the case of 4a. This is because,
at the exit from the LET form, *STANDARD-OUTPUT* is rebound to a broadcast
stream that includes an already closed stream to foo.log.
-- Taiichi
∂30-Jun-86 1011 LOOSEMORE@UTAH-20.ARPA Re: Two functions for everything?
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 30 Jun 86 10:11:15 PDT
Date: Mon 30 Jun 86 11:09:16-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Re: Two functions for everything?
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860630115511.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <12218981356.18.LOOSEMORE@UTAH-20.ARPA>
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Mon 30 Jun 86 08:52:34-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Yeah, but where in CLtL do we provide a way to make functions with multiple
entry points? I certainly don't want to have to hand-code every single
function that does optional error checking in assembly language (or
whatever). The point I was trying to make was that, if we are serious
about making multiple levels of error checking part of the language, we
should also provide some high-level constructs for specifying what error
checking goes on when. Multiple entry points would be one way to implement
such a construct....
Why do you think CLtL has to specify how this is done? It is completely
in the domain of the implementation of the compiler, the linker and the
compiled function format. The only thing CLtL needs to specify is how
to get what you want, and I think it already has that with the safety
setting.
Setting the safety switch only seems like half the story to me. You still
have to provide some way to specify what error checking a given function
does for each value of the safety setting. The reason why I would prefer
to see this mechanism part of the language spec, rather than left up to
each implementation, is that there is no real distinction between "system"
code and "user" code in Lisp. Since most CL implementations are, in fact,
written *in* CL, chances are they would have some internal, high-level
hooks to do this anyway. (Although I suppose there is at least one
masochistic implementor out there who actually *likes* writing code in
assembly language! :-)) So why not make these hooks available to the
user?
The sort of thing I have in mind is like a declarative form that contains
the assertions about the arguments to a particular function, and the
"safety level" at which to test each assertion. It would be up to the
implementation to figure out how to wrap the tests around the body of the
function.
Personally, I think having to write error checking code at all is a
nuisance, and trying to manage multiple levels of error checking sounds
like a real nightmare. Unless we can come up with some abstractions for
dealing with the complexity, I suspect that a lot of implementors are
going to avoid messing with it entirely.
-Sandra
-------
∂30-Jun-86 1040 FAHLMAN@C.CS.CMU.EDU Two functions for everything?
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jun 86 10:40:21 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 30 Jun 86 13:40:14-EDT
Date: Mon, 30 Jun 1986 13:40 EDT
Message-ID: <FAHLMAN.12218986982.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Two functions for everything?
In-reply-to: Msg of 30 Jun 1986 13:09-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
It is impossible in a portable language spec to indicate exactly what
opimizations will be be available and how the user will control them.
The nature of these optimizations and the trade-offs they involve will
vary tremendously from one system to another. There are probably
optimzations that we haven't invented yet, but that will be part of
some Common Lisp implementation some day.
If an implementaiton wants to give its users access to all of the
individual policy switches so that they have precise control over which
optimizations are used, that's fine, but it is deeply non-portable.
The OPTIMIZE declaration gives the user a portable way of saying, in
general, what his preferences are. It is up to the implementor of each
system to turn these preferences into reasonable policy decisions, given
his system's particular tradeoffs. These decisions should be documented
for each implementation, but they cannot be standardized in any
meaningful way across very different implementations.
I am a bit skeptical of systems that allow the user to redefine what the
OPTIMIZE declaration does. It seems more tasteful to hard-wire the
optimize-to-policy mapping, but to give the really tense users an
implementation-dependent way to over-ride the OPTIMIZE settings and to
manipulate the individual policy switches directly.
Implementations will vary in how finely they allow the user to control
the degree of error checking, but I hope not too many will take the view
that "having to write error checking code at all is a nuisance". A
little trouble taken by the implementors can save a *LOT* of trouble for
the users later on.
-- Scott
∂30-Jun-86 1057 gls@Think.COM Re: Argument lists: a proposal to shoot at
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 30 Jun 86 10:56:21 PDT
Received: from katherine by Godot.Think.COM via CHAOS; Mon, 30 Jun 86 13:56:14 edt
Date: Mon, 30 Jun 86 13:57 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: Argument lists: a proposal to shoot at
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp@SU-AI.ARPA
In-Reply-To: <860627181505.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <860630135717.1.GLS@KATHERINE.THINK.COM>
Date: Fri, 27 Jun 86 18:15 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Fri, 27 Jun 86 14:45 EDT
From: Guy Steele <gls@Think.COM>
Date: 26 Jun 1986 19:17-EDT
From: NGALL@G.BBN.COM
How about keeping the number of functions down and eliminating the
'encoding' in MAX-ARGS, and using correct terminology with the
following one-function alternative to FUNCTION-MIN-ARGS, -MAX-ARGS,
-HAS-KEYWORD-PARAMETERS, and -KEYWORD-PARAMETERS. I think
FUNCTION-KEYWORD-PARAMETER-P addresses an idiom common enough to
warrant its own function.
FUNCTION-PARAMETERS function [Function]
Returns Q, P, R, K, a list of keywords explicitly accepted by the
function (order undefined), and A. Note that if K is false, the list
is necessarily empty.
I like one function to return all the information better than a bunch of
separate functions. As for whether it's better to return min-and-max or
required-and-optional, in all these years I've never made up my mind on
that point. I do think it's a good idea for the presence of &rest or &key
not to throw away the information about how many positional parameters
there are, even if some of the proposed uses for that information are
bad ideas. In the min-and-max model, max could be the maximum number
of positional parameters, thus you have to look at (OR R K) to know
whether this is actually the maximum you are permitted to pass.
MIN-and-MAX is somewhat more like the :START/:END convention for subsequences;
required-nad-optional is like start/count. That is why I chose min and max.
I have to admit (blush) that another design criterion I employed implicitly
was that it should be possible to acquire most of the information without
either consing on the fly or requiring an explicit pre-stored list of the
keywords.
I don't understand how the information would be accessible at all if
there was not a pre-stored list. Perhaps you have some clever
implementation in mind?
If I were doing this on a PDP-10, I might arrange for the keywords to be checked
by stylized code at the start of each function, and would write a little routine
that could grovel through the instructions looking for the keywords.
In your proposal for FUNCTION-PARAMETERS, I observe that returning K
is redundant: K is true iff [(the keyword list is not empty) or A].
That's not to say that returning K separately isn't a good idea.
(defun foo (&key) ...) has some semantic meaning, namely that if this
function is ever extended it's going to take keyword parameters. If you
don't think this is a realistic example, see CLtL page 427.
I don't think clever elimination of the K return value is advisable.
Maybe it's not worth eliminating K, I grant. However, while it may be
reasonable for the author of the code to write (&key), it's not clear
that that information is important to a potential caller who needs to
know what arguments may be passed. Such a function accepts no keyword
arguments directly, and does not have &allow-other-keys, and so,
operationally speaking, what is the need to know that &key was there?
--Guy
∂30-Jun-86 1103 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: Two functions for everything?
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 30 Jun 86 11:02:08 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 32541; Mon 30-Jun-86 13:53:03 EDT
Date: Mon, 30 Jun 86 13:53 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Two functions for everything?
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>, DCP@QUABBIN.SCRC.Symbolics.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12218981356.18.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860630135301.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon 30 Jun 86 11:09:16-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Setting the safety switch only seems like half the story to me. You still
have to provide some way to specify what error checking a given function
does for each value of the safety setting. The reason why I would prefer
to see this mechanism part of the language spec, rather than left up to
each implementation, is that there is no real distinction between "system"
code and "user" code in Lisp. Since most CL implementations are, in fact,
written *in* CL, chances are they would have some internal, high-level
hooks to do this anyway. (Although I suppose there is at least one
masochistic implementor out there who actually *likes* writing code in
assembly language! :-)) So why not make these hooks available to the
user?
I'm still not sure I understand you, but I have thought up one scenario.
I was thinking that what safety affected were things that "are an error"
as defined by the language. This includes such things as AREF out of
bounds, calling a function with the wrong number of arguments, etc.
Under this view, if I compile
(defun foo (a) (car a))
with safety 0, the implementation may encode CAR inline. If I compile
it with safety 1, speed fast, it might compile as if I had written
(defun foo (a) (check-type a 'list) (and a (car a)))
If I compile it with safety 3, speed slow, space small, it might compile
as
(defun foo (a) (call-car's-full-checking-entrypoint a))
Some other settings might make it compile as
(defun foo (a) (call-car's-no-checking-entrypoint a))
[Seems silly for CAR, but consider a slightly larger function, such as
AREF.]
Maybe what you are saying is that the user might write
(defun foo (a) (check-type a 'list) (and a (car a)))
but might want to allow the check-type to be avoided if a caller of FOO
was compiled with safety 0. I don't know what to do about this. One
theory, which I think I believe, is that if a programmer puts in
explicit checking, that checking is always run.
The sort of thing I have in mind is like a declarative form that contains
the assertions about the arguments to a particular function, and the
"safety level" at which to test each assertion. It would be up to the
implementation to figure out how to wrap the tests around the body of the
function.
Personally, I think having to write error checking code at all is a
nuisance, and trying to manage multiple levels of error checking sounds
like a real nightmare. Unless we can come up with some abstractions for
dealing with the complexity, I suspect that a lot of implementors are
going to avoid messing with it entirely.
If I write a function that I expect other programmers to call, I usually
put in some error checking. I don't find it a nuisance, I find it a
benefit to make sure (a) they get the error messages they deserve at a
reasonable time, and (b) to make sure assumptions about the data I make
are valid (because they passed the tests).
Isn't this is a tug-of-war between speed and robustness on stock
hardware? Special hardware is usually designed to do both. CLtL tries
to give users the option of speed or robustness. I'm under the
impression this is a compile-time-only choice, and that you would like a
run-time choice as well?
∂30-Jun-86 1149 JAR@AI.AI.MIT.EDU Argument lists: a proposal to shoot at
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 30 Jun 86 11:46:20 PDT
Date: Mon, 30 Jun 86 14:30:51 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Argument lists: a proposal to shoot at
To: gls@ZARATHUSTRA.THINK.COM
cc: common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Mon 30 Jun 86 13:57 EDT from Guy Steele <gls at Think.COM>
Message-ID: <[AI.AI.MIT.EDU].63675.860630.JAR>
Date: Mon, 30 Jun 86 13:57 EDT
From: Guy Steele <gls at Think.COM>
Maybe it's not worth eliminating K, I grant. However, while it may be
reasonable for the author of the code to write (&key), it's not clear
that that information is important to a potential caller who needs to
know what arguments may be passed. Such a function accepts no keyword
arguments directly, and does not have &allow-other-keys, and so,
operationally speaking, what is the need to know that &key was there?
If the formal parameter list is (&key), then an actual parameter list of
(:foo 7 :allow-other-keys t :bar 'a) is legal, n'est-ce pas?
∂30-Jun-86 1216 gls@Think.COM Argument lists: a proposal to shoot at
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 30 Jun 86 12:15:36 PDT
Received: from katherine by Godot.Think.COM via CHAOS; Mon, 30 Jun 86 14:54:30 edt
Date: Mon, 30 Jun 86 14:55 EDT
From: Guy Steele <gls@Think.COM>
Subject: Argument lists: a proposal to shoot at
To: JAR@AI.AI.MIT.EDU, gls@ZARATHUSTRA
Cc: common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA, gls@AQUINAS
In-Reply-To: <[AI.AI.MIT.EDU].63675.860630.JAR>
Message-Id: <860630145533.6.GLS@KATHERINE.THINK.COM>
Date: Mon, 30 Jun 86 14:30:51 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Date: Mon, 30 Jun 86 13:57 EDT
From: Guy Steele <gls at Think.COM>
Maybe it's not worth eliminating K, I grant. However, while it may be
reasonable for the author of the code to write (&key), it's not clear
that that information is important to a potential caller who needs to
know what arguments may be passed. Such a function accepts no keyword
arguments directly, and does not have &allow-other-keys, and so,
operationally speaking, what is the need to know that &key was there?
If the formal parameter list is (&key), then an actual parameter list of
(:foo 7 :allow-other-keys t :bar 'a) is legal, n'est-ce pas?
Touche! Magnifique! (Or, as Frank Zappa titled an album, Zoot allures!)
What a wonderful language. Therefore the K value is not redundant after all.
--Guy
∂30-Jun-86 1301 LOOSEMORE@UTAH-20.ARPA Re: Two functions for everything?
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 30 Jun 86 13:01:39 PDT
Date: Mon 30 Jun 86 13:59:54-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Re: Two functions for everything?
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860630135301.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <12219012418.13.LOOSEMORE@UTAH-20.ARPA>
I was under the impression that we were discussing a proposal to standardize
what kinds of error checking certain functions (like CAR and AREF and SUBSEQ)
should perform when called from code compiled with various settings of the
"optimize safety" switch. The main reason why I would like to have a
standard, high-level utility to do such things is so that ordinary users
would have a portable way to provide various levels of error checking for
functions they write themselves. Secondarily, it's a lot of work for us
implementors to have to write 4 different versions of each of these
functions (or hand-code them with 4 entry points) and manually add special
hooks so the compiler will know about them. I think a more general utility
would be less work in the long run. Furthermore, I think that there's a
much better chance that various implementors could agree to do the same
kinds of error checks if it were easy to do so, instead of requiring a lot
of special-purpose hackery.
Conditional compilation of in-line error checks based on the current value
of the safety setting is another matter entirely. Again, the language
doesn't provide any portable way to do this, but it doesn't really sound
like such an unreasonable thing for a user to want to do.
Parenthetically, I might point out that this is similar to the problems
involved with implementing generic arithmetic and sequence functions. CL
puts so much emphasis on polymorphic functions it's somewhat annoying that
there aren't built-in utilities for ordinary users to use to define their
own polymorphic functions and make them known to the compiler in a portable
way. It would be real nice to have a way to generate dispatching code
automatically, and optionally hook into the compiler so it can make use of
declarations to do generic-to-specific optimizations. It's especially
annoying because probably most implementations already have some internal
mechanisms to do this (and those that don't would benefit from having
them, if experience with PSL/PCLS is anything to go by). And, I don't
think there's anything inherently nonportable about such a utility.
-Sandra
-------
∂30-Jun-86 1443 DESMEDT%HNYKUN52.BITNET@WISCVM.ARPA request to join
Received: from WISCVM.WISC.EDU by SU-AI.ARPA with TCP; 30 Jun 86 14:42:49 PDT
Received: from (DESMEDT)HNYKUN52.BITNET by WISCVM.ARPA on 06/30/86 at
16:43:06 CDT
Date: Mon, 30 Jun 86 12:19 N
From: <DESMEDT%HNYKUN52.BITNET@WISCVM.ARPA>
Subject: request to join
To: common-lisp@su-ai.arpa
X-Original-To: common-lisp@su-ai.arpa
I would like to be on the e-mailing list of the Common Lisp discussion
group. I am currently working on Natural Language applications (in Common
Lisp, of course) and have been involved in the development of an
object-oriented language on top of Common Lisp (CommonOrbit).
Koenraad De Smedt
University of Nijmegen
Psychology Lab
Montessorilaan 3
6525 HR Nijmegen
The Netherlands
e-mail: desmedt@hnykun52.bitnet
∂30-Jun-86 1748 Masinter.pa@Xerox.COM signalling errors
Received: from XEROX.COM by SU-AI.ARPA with TCP; 30 Jun 86 17:48:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 JUN 86 17:48:37 PDT
Date: 30 Jun 86 17:43 PDT
From: Masinter.pa@Xerox.COM
Subject: signalling errors
To: common-lisp@su-ai.ARPA
Message-ID: <860630-174837-3346@Xerox>
I think that changing "is an error" to "signals an error" is premature
until the error-handler is adopted and we can actually standardize
*which error* is signalled.
Before there is an error standard, neither phrase has particularly
well-defined semantics, and choosing between one and the other is
(nearly) moot.
After there is an error standard, there will be much more to decide for
each one. Further, the "hardship" question is much more restrictive --
implementations may not find it hard to signal some error, but there may
be many more difficulties in getting implementations to agree on the
error type.
∂30-Jun-86 1859 FAHLMAN@C.CS.CMU.EDU signalling errors
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jun 86 18:59:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 30 Jun 86 21:40:02-EDT
Date: Mon, 30 Jun 1986 21:39 EDT
Message-ID: <FAHLMAN.12219074228.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Subject: signalling errors
In-reply-to: Msg of 30 Jun 1986 20:43-EDT from Masinter.pa at Xerox.COM
I think that changing "is an error" to "signals an error" is premature
until the error-handler is adopted and we can actually standardize
*which error* is signalled.
OK, technically we should probably do this after KMP has brought forth
his revised error proposal and implementation, and after we have debated
that system and the alternatives. Everything depends on everything else
to some extent. But I think that this issue of whether certain errors
must be detected if the user asks for safety would look the same
regardless of the details of the error handler. I'd like to try to
reach a conclusion on this. We can re-open this issue if the error
system ultimately adopted has some unforseen consequences. For now,
let's just assume that distinct errors must be signalled for "too many
arguments', "too few arguments", "array access out of bounds", and
"attempt to take CAR/CDR of a non-list".
-- Scott
∂30-Jun-86 2025 FAHLMAN@C.CS.CMU.EDU Argument lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Jun 86 20:25:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 30 Jun 86 23:25:06-EDT
Date: Mon, 30 Jun 1986 23:25 EDT
Message-ID: <FAHLMAN.12219093455.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Argument lists
Perhaps we can try to converge on the argument-list business. Nick
Gall's proposal seems to be the leading contender for a low-cost
standard way of finding out how a function may legally be called. This
is an upward-compatible extension to the language:
---------------------------------------------------------------------------
(function-parameter <function>)
Takes one argument which must be a function, not a macro or special
form.
Returns the following six values:
1. Number of required parameters in the function's lambda list.
2. Number of optional parameters in the function's lambda list.
3. T if the function's lambda list contains the &REST lambda-keyword;
NIL otherwise.
4. T if the function's lambda list contains the &KEY lambda-keyword;
NIL otherwise.
5. A list of all keywords accepted by the function, in arbitrary order.
6. T if the function's lambda list contains the &ALLOW-OTHER-KEYS
lambda-keyword; NIL otherwise.
If return value 4 is NIL, 5 and 6 must also be NIL.
---------------------------------------------------------------------------
Can everyone live with that? If not, say so.
There seems to be little enthusiasm for REQUIRING that an implementation
supply the function's original argument list or the names of the
parameters, especially for compiled code. There remains the issue of
whether we should provide a standard way of asking for additional,
internal argument list information if it is available. Some
implementations would supply this information, others would not, and
others might supply it for some functions and not for others.
I personally believe that a standard format for getting at argument-name
information, if it is available, would be useful, but I don't like the
idea of returning the original lambda-list (or a copy of it). The
problem is that the lambda-list contains default-value forms that can be
very complex and that would be confusing when taken out of context. I'd
prefer something like the following, to be used in conjunction with
Function-Parameter as defined above:
---------------------------------------------------------------------------
(function-parameter-names <function>)
Takes one argument which must be a function, not a macro or special
form.
Returns two values:
1. A list containing the symbols naming the required, optional, and rest
parameters, in order, if this information is available; NIL
otherwise.
2. T if the list returned as value 1 is valid; NIL otherwise.
---------------------------------------------------------------------------
Would something like this be useful in the standard, or should we let
each implementation decide for itself wht format to use in providing
arglist info?
-- Scott
∂01-Jul-86 0350 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA function keys
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 1 Jul 86 03:50:40 PDT
Received: from utokyo-relay by csnet-relay.csnet id ak08281; 1 Jul 86 6:36 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA14426; Tue, 1 Jul 86 14:10:30+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA09337; Tue, 1 Jul 86 14:06:56+0900
Date: Tue, 1 Jul 86 14:06:56+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607010506.AA09337@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida@UTOKYO-RELAY.CSNET,
ida%u-tokyo.junet@CSNET-RELAY.ARPA
Subject: function keys
>Date: Fri, 20 Jun 86 10:37 EDT
>From: "Daniel L. Weinreb" <DLW%SCRC-QUABBIN.ARPA@u-tokyo.junet>
>Subject: Re: Why aren't char bits portable?
This mail is not directly related to this subject.
But, I want to talk about the keyboard interface.
>To: Masinter.pa@XEROX.COM, common-lisp@SU-AI.ARPA
>Received: from CSNet-Relay by utokyo-relay; 22 Jun 86 7:27:22-JST (Sun)
>
> ... I believe that the intent of including
>"bits" in the standard is to allow for the fact that some of the "bits"
>are gaining some amount of currency as ad hoc standards.
If "bits" are gaining some amount of currency as ad hoc standard,
"function-keys" are also gaining some amount of currency as ad hoc standard,
in japan. (I am not talking about the character issues here.
I am talking about the ad hoc standard for keyboard interfaces)
> ... In particular,
>there are now several terminals on the market that have a "Meta" key,
> ...
There are now MANY terminals/personal computers that have "function-keys"
in Japan.
>
>A program that wants to be universally portable, of course, cannot
>depend on the presence of such key on the user's keyboard. However, it
>is not hard to imagine a program that wants to be portable, but also
>wants to allow any user who has a Meta key to take advantage of it.
>(Indeed, many Emacs-family editors have this property.)
>
>I believe the intention of the "bits" feature was to help out such
>programs. While I'm not sure that all the details of the "bits" feature
>in the standard are ideal, nevertheless I wanted to point out that the
>entire feature is not necessarily bankrupt.
>
>
Actually, there are discussions about the standard interface for "function-keys" in CL in japan.
I was asked the possibility of the standard for it.
Lisp based interactive system faces the problem.
There arises a portability problem.
Furthremore many editor/word processing software in japan use function keys.
The semantics for the function keys may vary. There may be 10 function keys physically,
and with shift-key they act as a command pannel for 20 functions.
The meaning of the each key is guided in CRT.
Or a guide pad for each software is provided for user convinience.
I wonder this type of standardization for interface is japan domestic or no ?
Masayuki Ida
ida@utokyo-relay.csnet
∂01-Jul-86 0556 Hvatum.DLAB@MIT-MULTICS.ARPA subseq
Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 1 Jul 86 05:56:09 PDT
Date: Tue, 1 Jul 86 08:41 EDT
From: Hvatum@MIT-MULTICS.ARPA
Subject: subseq
To: common-lisp@SU-AI.ARPA
Message-ID: <860701124137.380202@MIT-MULTICS.ARPA>
From: Steve Bacher (C.S.Draper Lab)
To: common-lisp <common-lisp at SU-AI>
Subject: subseq
How about
(subseq #(1 2 3) 0 5 :signal-error nil) ?
This seems ideal to me, since the programmer's intention (i.e. whether
or not an out-of-bounds condition is expected) is stated right there in
the function call form.
∂01-Jul-86 0640 NGALL@G.BBN.COM Re: Argument lists
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 1 Jul 86 06:39:15 PDT
Date: 1 Jul 1986 09:38-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Argument lists
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 1-Jul-86 09:38:16.NGALL>
In-Reply-To: <FAHLMAN.12219093455.BABYL@C.CS.CMU.EDU>
Date: Mon, 30 Jun 1986 23:25 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Argument lists
Message-ID: <FAHLMAN.12219093455.BABYL@C.CS.CMU.EDU>
Perhaps we can try to converge on the argument-list business. Nick
Gall's proposal seems to be the leading contender for a low-cost
standard way of finding out how a function may legally be called. This
is an upward-compatible extension to the language:
---------------------------------------------------------------------------
(function-parameter <function>)
I think this is a typo. Should be function-parameters.
...
---------------------------------------------------------------------------
(function-parameter-names <function>)
Takes one argument which must be a function, not a macro or special
form.
Returns two values:
1. A list containing the symbols naming the required, optional, and rest
parameters, in order, if this information is available; NIL
otherwise.
2. T if the list returned as value 1 is valid; NIL otherwise.
---------------------------------------------------------------------------
Would something like this be useful in the standard, or should we let
each implementation decide for itself wht format to use in providing
arglist info?
Looks fine (and useful) to me.
-- Nick
∂01-Jul-86 0714 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Argument lists
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 1 Jul 86 07:14:06 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3458; 1 Jul 86 10:15:29-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 26712; Tue 1-Jul-86 10:15:22-EDT
Date: Tue, 1 Jul 86 10:13 EST
Sender: mike@a
To: Fahlman@C.CS.CMU.EDU
From: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: Argument lists
Cc: common-lisp@SU-AI.ARPA
Date: Mon, 30 Jun 1986 23:25 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Perhaps we can try to converge on the argument-list business. Nick
Gall's proposal seems to be the leading contender for a low-cost
standard way of finding out how a function may legally be called. This
is an upward-compatible extension to the language:
I still think the right thing to do is to make (type-of <function>)
return a type signature for the function. Then the user's program can
conclude whatever it wants. If an implementation can do this, then it
can certainly do what is required below, and other things too,
depending on how specific the type signature is. I proposed this last
week sometime, and I saw only minimal feedback (which was positive).
Are there any good reasons why the type system isn't the right place
to garner this information?
The only real objection that I can see to this is that creating
function-specs may require consing them up, or storing them
previously.
There seems to be little enthusiasm for REQUIRING that an implementation
supply the function's original argument list or the names of the
parameters, especially for compiled code.
Agreed. I think this is a programming environment issue, not a
Language definition issue.
There remains the issue of
whether we should provide a standard way of asking for additional,
internal argument list information if it is available. Some
implementations would supply this information, others would not, and
others might supply it for some functions and not for others.
I personally believe that a standard format for getting at argument-name
information, if it is available, would be useful, but I don't like the
idea of returning the original lambda-list (or a copy of it). The
problem is that the lambda-list contains default-value forms that can be
very complex and that would be confusing when taken out of context.
Just the argument names can be misleading. A broken abstraction is a
broken abstraction. On the other hand, if you are going to allow
people the "documentation" value of knowing the formal parameter
names, I don't see why you draw the line at the default forms. They
can be useful to look at as well, for example to decide if you need
to calculate and pass an optional argument, or whether the default is
good enough.
Would something like this be useful in the standard, or should we let
each implementation decide for itself wht format to use in providing
arglist info?
I don't see much agreement on this issue.
-- Scott
...mike
∂01-Jul-86 0825 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 1 Jul 86 08:24:48 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3460; 1 Jul 86 11:26:00-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 26728; Tue 1-Jul-86 11:25:53-EDT
Date: Tue, 1 Jul 86 11:23 EST
From: mike@a
To: Masinter.pa@Xerox.COM
Subject:
Cc: common-lisp@su-ai.ARPA
Date: 26 Jun 86 15:36 PDT
From: Masinter.pa@Xerox.COM
Sounds like I wasn't clear enough.
When I suggested portable programs "stick within the set of standard
characters" I was referring to "the Common Lisp character set" as
defined on pp 20-21 of "Common Lisp the Language" by Guy L. Steele Jr.
as follows:
"The Common Lisp character set consists of a space character #\Space, a
newline character #\Newline, and the following ninety-four non-blank
printing characters or their equivalents..."
It looks awfully specific to me, and I'm not sure what our friends at
IBM or Japan would be chuckling about.
In reply to KMPs other points:
"It's important to distinguish between implementation dependent behavior
and unpredictable behavior. Many things in Common Lisp are conceptually
well-defined even though they vary from implementation to
implementation. For example, the behavior of (1+ MOST-POSITIVE-FIXNUM)
varies in detail from implementation to implementation, but
conceptually it does not. I don't think that it's inappropriate to
describe a program as having useful commands bound to keys and to tell
the user to type "?" to see a list of the commands available."
I agree whole-heartedly with this analysis and the appropriateness of
the situation you describe.
"The issue is much bigger than you make it out to be and if you claim it
to be fatal, then I claim you're attacking the whole notion of whether
CL can be portable..."
I object to your claim: I firmly believe that CL can be portable and I'm
making no such attack. That's the point of this whole discussion. I
think that this is in fact one of the few intrinsicly non-portable parts
of the language.
I agree that CHAR-BITS-LIMIT is in the same class as
"MOST-POSITIVE-FIXNUM". The issue as I see it is: does this abstraction
*encourage* or *discourage* users from writing portable programs?
I claim that this particular feature works against portability: It is my
belief that having "char-bits" in the book will encourage users who are
working in an implementation which supports "char-bits" to rely upon
"char-bits" in their programs, with a nod to the fact "well, those
lusers without char-bits just can't use this program".
If char-bits were *not* in the standard, then the writer of a portable
program would set aside a table somewhere, which said:
; implementation-dependent table of character codes and their functions
#\control-A delete-next-character
#\control-R retype-line
and clearly identify that these were not "standard" (in the sense of pp
20-21) characters. Let me put it in terms of a more definite proposal in
terms of chapter and verse:
a) eliminate constants char-code-limit, char-font-limit and
char-bits-limit, and instead have a constants:
char-integer-limit [Constant]
The value of char-integer-limit is a non-negative integer that is the
upper exclusive bound on values produced by the function char-integer.
...
string-char-integer-limit [constant]
The value of string-char-integer-limit is the upper exclusive bound on
values produced by the funcion char-integer for characters which satisfy
string-char-p.
[Implementation note: older Common Lisps can implement this by
(defconstant char-integer-limit (+ char-code-limit char-font-limit
char-bits-limit))
(defconstant string-char-integer-limit char-code-limit)]
b) change the wording of char-upcase and char-downcase to omit
references to "characters with non-zero bits". [note: I detect an
inconsistency in the description of char-upcase on p. 241, which in the
second paragraph says that it returns a character object with the same
font and bits attributes but with possibly a different code, and in the
last paragraph says that they have no effect on characters with non-zero
bits attributes]
c) eliminate functions char-code, char-bits, char-font, code-char,
make-char from the standard.
[Compatibility note: users with older common lisp programs may want to
define char-code as (mod (char-int char) string-char-integer-limit)) and
similarly make the other ones as transforms on char-integers]
d) eliminate the constants char-control-bit char-meta-bit char-super-bit
char-hyper-bit and the functions char-bit set-char-bit. [Compatibility
note: users with older common lisp programs who want to use these
features can define these constants as 1 2 4 8 respectively, and define
(defun char-bit char name
(int-char (logtest (int-char char)
(* string-char-integer-limit (ecase name (:control 1) (:meta 2)
...))))))
∂01-Jul-86 0836 FAHLMAN@C.CS.CMU.EDU subseq
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Jul 86 08:36:26 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 1 Jul 86 11:36:02-EDT
Date: Tue, 1 Jul 1986 11:35 EDT
Message-ID: <FAHLMAN.12219226516.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Hvatum@MIT-MULTICS.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: subseq
In-reply-to: Msg of 1 Jul 1986 08:41-EDT from Hvatum at MIT-MULTICS.ARPA
(subseq #(1 2 3) 0 5 :signal-error nil) ?
This still looks like a really bad way of accomplishing whatever it is
you are trying to accomplish. A subsequence should be a SUBsequence,
period.
-- Scott
∂01-Jul-86 0839 FAHLMAN@C.CS.CMU.EDU Argument lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Jul 86 08:39:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 1 Jul 86 11:38:29-EDT
Date: Tue, 1 Jul 1986 11:38 EDT
Message-ID: <FAHLMAN.12219226944.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Argument lists
In-reply-to: Msg of 1 Jul 1986 09:38-EDT from NGALL at G.BBN.COM
(function-parameter <function>)
I think this is a typo. Should be function-parameters.
Right!
-- Scott
∂01-Jul-86 0901 FAHLMAN@C.CS.CMU.EDU Argument lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Jul 86 09:00:30 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 1 Jul 86 12:00:32-EDT
Date: Tue, 1 Jul 1986 12:00 EDT
Message-ID: <FAHLMAN.12219230969.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Argument lists
In-reply-to: Msg of 1 Jul 1986 11:13-EDT from mike%gold-hill-acorn at mit-live-oak.arpa
I still think the right thing to do is to make (type-of <function>)
return a type signature for the function. ... I proposed this last
week sometime, and I saw only minimal feedback (which was positive).
Are there any good reasons why the type system isn't the right place
to garner this information?
Sorry I didn't jump on this when it was first proposed. Too much mail
went by in too short a time.
I really dislike this way of doing it. Several reasons: First, this is
a very inconvenient interface. We require the system to cons up a funny
list that the user then has to parse. Second, it requires the type of
every argument to be available in explicit form; this may be too much to
ask of many systems. Third, TYPE-OF has a lot of leeway in what it
returns for all other forms, and is the source of much confusion. I've
seen several portable packages try to use this and get screwed up
because they expected STRING and got (SIMPLE-STRING 37) or something. I
would like to promote the idea that TYPE-OF is useful mostly as an
interactive debugging interface, and if you ever see TYPE-OF in code it
is probably an error.
Just the argument names can be misleading. A broken abstraction is a
broken abstraction. On the other hand, if you are going to allow
people the "documentation" value of knowing the formal parameter
names, I don't see why you draw the line at the default forms. They
can be useful to look at as well, for example to decide if you need
to calculate and pass an optional argument, or whether the default is
good enough.
I don't see this as a broken abstraction. The programmer needs to know
which arguments are supposed to do what, and the names are a quick way
of indicating that (or at least what the argument order is if the user
already knows what the function is supposed to do). Documentation
strings typically say something like "Takes two arguments, ITEM and
LIST, and looks for the second occurrence of ITEM in LIST..." The
proposed function would give you the first half of that. It doesn't
tell you what's in the black box. It doesn't tell you anything you
wouldn't get from an Ada function header.
If all the default forms were constants, I'd argue for including those
as well, but they are arbitrary forms of unbounded complexity that cross
the line into implementation in many cases.
-- Scott
∂01-Jul-86 0955 gls@Think.COM Argument lists
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 1 Jul 86 09:55:16 PDT
Received: from katherine by Godot.Think.COM via CHAOS; Tue, 1 Jul 86 12:55:14 edt
Date: Tue, 1 Jul 86 12:56 EDT
From: Guy Steele <gls@Think.COM>
Subject: Argument lists
To: mike%gold-hill-acorn@mit-live-oak.ARPA, Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <8607011415.AA08297@Zarathustra.Think.COM>
Message-Id: <860701125623.3.GLS@KATHERINE.THINK.COM>
Date: Tue, 1 Jul 86 10:13 EST
From: mike%gold-hill-acorn@mit-live-oak.ARPA
Date: Mon, 30 Jun 1986 23:25 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Perhaps we can try to converge on the argument-list business. Nick
Gall's proposal seems to be the leading contender for a low-cost
standard way of finding out how a function may legally be called. This
is an upward-compatible extension to the language:
I still think the right thing to do is to make (type-of <function>)
return a type signature for the function.
The problem is more general than that. Sometimes you just want the
word FUNCTION and sometimes the more elaborate thing. There is not
enough control over what TYPE-OF returns, and that, in turn, is because
there are many possible types to which an object might belong.
--Guy
∂01-Jul-86 0958 gls@Think.COM Argument lists
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 1 Jul 86 09:58:01 PDT
Received: from katherine by Godot.Think.COM via CHAOS; Tue, 1 Jul 86 12:58:04 edt
Date: Tue, 1 Jul 86 12:59 EDT
From: Guy Steele <gls@Think.COM>
Subject: Argument lists
To: Fahlman@C.CS.CMU.EDU, NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <FAHLMAN.12219226944.BABYL@C.CS.CMU.EDU>
Message-Id: <860701125913.4.GLS@KATHERINE.THINK.COM>
Date: Tue, 1 Jul 1986 11:38 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
(function-parameter <function>)
I think this is a typo. Should be function-parameters.
Right!
-- Scott
With this amendment, I endorse this proposal and retract the
several functions I suggested initially.
--Guy
∂01-Jul-86 1104 Bobrow.pa@Xerox.COM Re: Argument lists
Received: from XEROX.COM by SU-AI.ARPA with TCP; 1 Jul 86 11:04:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUL 86 11:04:31 PDT
Date: 1 Jul 86 10:22 PDT
Sender: Bobrow.pa@Xerox.COM
Subject: Re: Argument lists
In-reply-to: mike%gold-hill-acorn@mit-live-oak.arpa's message of Tue, 1
Jul 86 10:13 EST
To: mike%gold-hill-acorn@mit-live-oak.arpa
cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
From: Bobrow.pa@Xerox.COM (Danny Bobrow)
Message-ID: <860701-110431-3911@Xerox>
I still think the right thing to do is to make (type-of <function>)
return a type signature for the function. Then the user's
program can conclude whatever it wants.
I support this idea, especially since it extends well to the notion of
generic functions where type information is specified.
-- danny
∂01-Jul-86 1108 Gregor.pa@Xerox.COM Re: Argument lists
Received: from XEROX.COM by SU-AI.ARPA with TCP; 1 Jul 86 11:08:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUL 86 11:08:15 PDT
Date: 1 Jul 86 10:42 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Argument lists
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Mon,
30 Jun 86 23:25 EDT
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <860701-110815-3923@Xerox>
It might be better if function-parameter-names returned 4 values by
splitting its first value up into 3 separate values. The required, the
optional and the rest. This would make it easier for programs which
just want to print the parameters of a function, they wouldn't have to
both function-parameter-names and function-parameters (using the values
from the second to split up the values from the second).
If function-parameter-names gets changed that way, the spec has to make
it very clear whether the values returned can be bashed since people who
want just one value (all the argument names) are going to have to decide
whether to use nconc or append.
∂01-Jul-86 1335 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM function keys
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 1 Jul 86 13:35:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 33521; Tue 1-Jul-86 13:31:14 EDT
Date: Tue, 1 Jul 86 13:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: function keys
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8607010506.AA09337@ccut.u-tokyo.junet>
Message-ID: <860701133101.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Do function keys modify other characters that are pressed at the same
time (like SHIFT and META), or do they stand by themselves (like RETURN
and Q)? If they stand by themselves, then function keys can fit into
Common Lisp simply as twenty (or however many you have on the particular
keyboard) additional characters that are not STANDARD-CHAR-P and not
GRAPHIC-CHAR-P. I don't think the fact that some function keys are
entered with SHIFT ought to be reflected in CHAR-UPCASE and related
functions.
∂01-Jul-86 1335 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument lists
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 1 Jul 86 13:35:17 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 33510; Tue 1-Jul-86 13:26:40 EDT
Date: Tue, 1 Jul 86 13:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Argument lists
To: mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 1 Jul 86 11:13 EDT from mike%gold-hill-acorn@mit-live-oak.arpa
Message-ID: <860701132627.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 1 Jul 86 10:13 EST
From: mike%gold-hill-acorn@mit-live-oak.arpa
I still think the right thing to do is to make (type-of <function>)
return a type signature for the function. Then the user's program can
conclude whatever it wants. If an implementation can do this, then it
can certainly do what is required below, and other things too,
depending on how specific the type signature is. I proposed this last
week sometime, and I saw only minimal feedback (which was positive).
Are there any good reasons why the type system isn't the right place
to garner this information?
Doesn't this conflict with the possibility of (type-of <function>) telling
you whether it's an interpreted or compiled function, and whether it's
a closure or not, and (in some systems) whether it's generic or not?
Or, as CLtL says, "(type-of object) returns an implementation-dependent
result".
∂01-Jul-86 1338 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Argument lists
Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 1 Jul 86 13:38:40 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3490; 1 Jul 86 16:40:04-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 26904; Tue 1-Jul-86 16:39:47-EDT
Date: Tue, 1 Jul 86 16:09 EST
Sender: mike@a
To: Fahlman@C.CS.CMU.EDU
From: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: Argument lists
Cc: common-lisp@SU-AI.ARPA
Date: Tue, 1 Jul 1986 12:00 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I still think the right thing to do is to make (type-of <function>)
return a type signature for the function. ... I proposed this last
week sometime, and I saw only minimal feedback (which was positive).
Are there any good reasons why the type system isn't the right place
to garner this information?
Sorry I didn't jump on this when it was first proposed. Too much mail
went by in too short a time.
I really dislike this way of doing it. Several reasons: First, this is
a very inconvenient interface. We require the system to cons up a funny
list that the user then has to parse.
This is no harder than parsing a regular arglist; however, I see your
point. My complaint is not that there oughtn't be a digested numeric
version of this functionality, (and the circulated proposal seems
fine,) but rather this: The need to make statements about function
types in terms of arglists is indicative of a shortcoming in the type
system of CL. The shortcoming is that you can't find out anything
about the type of a function object.
Second, it requires the type of
every argument to be available in explicit form; this may be too much to
ask of many systems.
Actually, the types of the arguments can always be t, e.g.,
(function (t t &key t ) (values t t))
Which additionally hides the names of the variables.
Third, TYPE-OF has a lot of leeway in what it
returns for all other forms, and is the source of much confusion.
Right. I think the leeway should be removed, so that it is no
longer confusing. CLtL defines a powerful and elegant type system
for lisp. Things like type-of should be tools that programmers can use
rather than underspecified thorns in the side.
I've
seen several portable packages try to use this and get screwed up
because they expected STRING and got (SIMPLE-STRING 37) or something.
This is the equality bug all over again on types. Subtypep is usually
the right comparison to use for types, not list equality. Typep is generally
too strong as well.
I would like to promote the idea that TYPE-OF is useful mostly as an
interactive debugging interface, and if you ever see TYPE-OF in code it
is probably an error.
This is the way I feel about arglist accessing functions! They should be
part of an interactive debugging interface, not part of applications code.
And if you see programs manipulating arglists or asking about them, it
is probably something better stated in terms of the type of the
function involved.
...mike beckerle
Gold Hill Computers
∂01-Jul-86 1429 berman@vaxa.isi.edu Validation status
Received: from VAXA.ISI.EDU by SU-AI.ARPA with TCP; 1 Jul 86 14:14:44 PDT
Received: by vaxa.isi.edu (4.12/4.7)
id AA18071; Tue, 1 Jul 86 14:14:20 pdt
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8607012114.AA18071@vaxa.isi.edu>
Date: 1 Jul 1986 1414-PDT (Tuesday)
To: common-lisp@su-ai.arpa
Cc:
Subject: Validation status
Validation Suite Report 01 July 1986
Currently I have just (in the past 10 days) actually received the first few
signifigant (in size) contributions. By and large these are only partially
evaluated at this time. Each validation suite contributed uses its own form
of test control and reporting. At present I am looking over the various
control mechanisms, as well as cataloging and understanding (or trying to) the
various individual tests.
The following shows the status of each contributor.
THINGS RECEIVED:
CDC - Tape received from them yesterday, containing large test suite.
Coral Software - Brought a Macintosh disk with shallow tests of a number of CL
functions.
Gould Computer Systems - Sent a test suite for Arrays. Also sent a manual for
their "test harness" test controller, but did not send the source code for the
test controller run-time, macro definitions, etc. I have asked for this
extra data.
THINGS PROMISED:
Data General - Currently sanitizing a broad/shallow suite. Should be ready
soon.
DEC - Has promized a suite for FORMAT, may do more as this public domain suite
progresses.
Franz - Has promised "something" after the 4th.
H.P. -- Around June 19 they said they'd send "everything", which would be a
large test suite. There may have been some hitch in figuring out how to send
it in a form that I can use it.
Symbolics - In May said they'd sanitize and send in a full test suite around
the beginning of June. I am not sure of the cause for the delay, but I can
imagine that this project is not a high priority.
T.I. - Will do something. I've suggested a scoping test (hee hee hee).
------------------------
OTHER THINGS:
I'd love to hear from any of the following, 'cuz I either have been unable to
et your corret net address or for some other reason we have not connected:
AT&T Bell Labs -- Elia Weixelbaum
Gold Hill -- Greg Faust
Integrated Inference Machines -- James H. Hind
Intermetrics -- Karen Huff
LMI -- George Carrette
Pyramid Technology -- David Bein
Tektronix -- William Waller
Xerox AIS -- Paul Ricci
----------------------------
In addition there is the ISI proposal on their involvement in supporting the
Common Lisp community. It goes much beyond just the validation suite. Please
send a message to me, Berman@Vaxa.ISI.EDU, if you would like to see this.
Best,
RB
∂01-Jul-86 1527 FAHLMAN@C.CS.CMU.EDU Validation status
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Jul 86 15:27:17 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 1 Jul 86 18:27:20-EDT
Date: Tue, 1 Jul 1986 18:27 EDT
Message-ID: <FAHLMAN.12219301393.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: berman@λvaxa.isi.edu (Richard Berman)λ
Cc: common-lisp@SU-AI.ARPA
Subject: Validation status
In-reply-to: Msg of 1 Jul 1986 17:14-EDT from berman at vaxa.isi.edu (Richard Berman)
Richard,
Thanks for the progress report. I don't see Lucid in there anywhere.
have they reneged on their promise?
I'd like to have a look at the support proposl you're sending in. In
fact, all of the technical and steering committee members should
probably see this. They can all be reached by mail to
CL-Steering@su-ai. Ohlander is on the steering committee if there are
questions.
Glad to see you're rolling.
-- Scott
∂01-Jul-86 1638 KMP@STONY-BROOK.SCRC.Symbolics.COM Argument lists
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Jul 86 16:38:16 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 45410; Tue 1-Jul-86 19:37:55 EDT
Date: Tue, 1 Jul 86 19:36 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Argument lists
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12219093455.BABYL@C.CS.CMU.EDU>
Message-ID: <860701193628.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 30 Jun 1986 23:25 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Subject: Argument lists
... Nick Gall's proposal seems to be the leading contender for a low-cost
standard way of finding out how a function may legally be called. ...
(function-parameter <function>)
Returns ... six values ...
Can everyone live with that? If not, say so.
No. This does not assure adequately fast access to just the max and min
information for use in embedded interpreters. The other info might be
expensive to cons and it may be getting consed for no good reason. I feel
that either there should be two functions, or the function should be given
arguments saying kinds of info you wanted so that no time was wasted in
consing in situations where speed matters. This wouldn't be so essential
if implementations were always required to signal an error in an wrong
number of arguments situation -and- if we had the error system in place.
I expect the latter to happen in the near future, but am not so sure the
former will go through, so I really think fast access to just the numbers
part is important.
∂01-Jul-86 1935 FAHLMAN@C.CS.CMU.EDU Open keyboard, insert foot.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Jul 86 19:35:49 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 1 Jul 86 22:35:55-EDT
Date: Tue, 1 Jul 1986 22:35 EDT
Message-ID: <FAHLMAN.12219346648.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Open keyboard, insert foot.
I intended that my reply to Richard Berman's message about validation
suites would go to him alone. It was sent to Common Lisp by accident.
My question about whether Lucid had "reneged" was meant as a
semi-humorous way of asking Richard why Lucid was not on the "expect
something soon" list, when he and I both knew that Lucid intended to
participate in the validation process. I would not have expressed it
this way in a message meant for the wider Common Lisp community, where
it could easily have been misunderstood.
Since I have broadcast this poorly worded question by accident, let me
also broadcast the answer: Lucid is working with the ISI people to
develop validation code that will properly reflect the revised spec that
we are working on now, rather than the current one; that is why they
weren't on Berman's list of current or near-future contributors.
My aplogies to Dick Gabriel and Lucid for any discomfort I may have
caused them. This is what happens when one tries to answer too many
mail messages in the course of an afternoon.
-- Scott
∂02-Jul-86 0535 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Portability and Code walkers
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 2 Jul 86 05:34:57 PDT
Received: from umass-cs by csnet-relay.csnet id bq03967; 2 Jul 86 1:42 EDT
Date: Mon, 30 Jun 86 15:47 EST
From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To: Common-Lisp@SU-AI.ARPA
Subject: Portability and Code walkers
On P56-58 CLtL defines special forms so that it is *almost* possible
to implement a portable code-walker. The loophole is that implementors
are only encouraged, not required, to implement CL macros so as
not to expand into implementation-dependant special forms. All of the
effort to make portable code-walkers possible is useless because of this
exception.
I don't think this exception is neeed. Instead, implementations should
use implementation-dependant optimizers to get the efficient
compilation, but still provide legitimate expansions. Another way
out would be to require implementations to provide macro-expansions of
all special forms that can be produced by macro-expansion of any
CL macro. The compiler could still use its implementation dependant
knowledge of the non-standard special form, while the code walker
could use the (less efficient) macro expansion.
A code walker written according to the description on P57 should be
included in the validation set. The code walker should be able to
walk all of the code in the validation examples.
∂02-Jul-86 0615 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA function keys
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 2 Jul 86 06:15:47 PDT
Received: from utokyo-relay by csnet-relay.csnet id ab05841; 2 Jul 86 6:29 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA05547; Wed, 2 Jul 86 17:10:26+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA03156; Wed, 2 Jul 86 16:48:42+0900
Date: Wed, 2 Jul 86 16:48:42+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607020748.AA03156@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@CSNET-RELAY.ARPA
Subject: function keys
>From common-lisp-request%csnet-relay.csnet@u-tokyo.junet Wed Jul 2 13:50:47 1986
>Date: Tue, 1 Jul 86 13:31 EDT
>From: "David A. Moon" <Moon%SCRC-STONY-BROOK.ARPA@u-tokyo.junet>
>Subject: function keys
>To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@csnet-relay.csnet>
>Cc: common-lisp@SU-AI.ARPA
>In-Reply-To: <8607010506.AA09337@ccut.u-tokyo.junet>
>Message-Id: <860701133101.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
>Received: from CSNet-Relay by utokyo-relay; 2 Jul 86 13:32:15-JST (Wed)
>
>Do function keys modify other characters that are pressed at the same
>time (like SHIFT and META), or do they stand by themselves (like RETURN
>and Q)? If they stand by themselves, then function keys can fit into
>Common Lisp simply as twenty (or however many you have on the particular
>keyboard) additional characters that are not STANDARD-CHAR-P and not
>GRAPHIC-CHAR-P. I don't think the fact that some function keys are
>entered with SHIFT ought to be reflected in CHAR-UPCASE and related
>functions.
>
>
Many personal computers which are also used as a low cost terminal in japan have function keys.
They can be assisted by SHIFT key.
It doubles the capability.
For example, if there are 10 function keys, pressing function 1 at the
same time with shift key acts as a function 11.
Logically, function keys can be viewed as independent keys,
even if they may be assisted by shift key.
So, by now, I think they are the (20 or other numbers of) additional characters that
are not STANDARD-CHAR-P and not GRAPHIC-CHAR-P as you stated.
Masayuki Ida
∂02-Jul-86 0837 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Argument lists
Received: from LIVE-OAK.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jul 86 08:37:40 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3552; 2 Jul 86 11:39:22-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 27010; Wed 2-Jul-86 11:33:20-EDT
Date: Wed, 2 Jul 86 11:30 EST
Sender: mike@a
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
From: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: Argument lists
Cc: common-lisp@SU-AI.ARPA
Date: Tue, 1 Jul 86 13:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 1 Jul 86 10:13 EST
From: mike%gold-hill-acorn@mit-live-oak.arpa
I still think the right thing to do is to make (type-of <function>)
return a type signature for the function.....
Doesn't this conflict with the possibility of (type-of <function>) telling
you whether it's an interpreted or compiled function, and whether it's
a closure or not, and (in some systems) whether it's generic or not?
Or, as CLtL says, "(type-of object) returns an implementation-dependent
result".
This depends on what you think type-of is supposed to do.
Maybe we need a new function name, but as far as I'm concerned,
closures, (compiled or not) and functions, can all have the same type,
that is (function (...) ...), as do all applicable objects.
However, their representations have different types. The question
really boils down to whether type-of is supposed to tell you something
about the CL type lattice, or the representation of the object.
My interpretation of CLtL was that type-of returns an implementation
dependent result, in that the "precision" of the type might vary
from one interpretation to another. The "weakest" type-of would return
types of defstructs, and type t for everything else. The strongest
(and certainly unachievable) type-of would return complete function
signatures for all applicable objects, etc. In every case, what is
returned is a CL type, not the rep type.
Generics are a much harder problem, since their type signatures can
be really elaborate. I assume you mean by generics the kind of
overloaded operators you can get in Commonloops and New Flavors?
Are the implications of these for the type system understood at all?
Will CL have anything left of a type system after this kind of
overloading becomes the norm, or can we somehow salvage it?
...mike beckerle
Gold Hill Computers.
∂02-Jul-86 0842 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Argument lists
Received: from LIVE-OAK.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jul 86 08:42:48 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3554; 2 Jul 86 11:44:56-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 27010; Wed 2-Jul-86 11:33:20-EDT
Date: Wed, 2 Jul 86 11:30 EST
Sender: mike@a
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
From: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: Argument lists
Cc: common-lisp@SU-AI.ARPA
Date: Tue, 1 Jul 86 13:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 1 Jul 86 10:13 EST
From: mike%gold-hill-acorn@mit-live-oak.arpa
I still think the right thing to do is to make (type-of <function>)
return a type signature for the function.....
Doesn't this conflict with the possibility of (type-of <function>) telling
you whether it's an interpreted or compiled function, and whether it's
a closure or not, and (in some systems) whether it's generic or not?
Or, as CLtL says, "(type-of object) returns an implementation-dependent
result".
This depends on what you think type-of is supposed to do.
Maybe we need a new function name, but as far as I'm concerned,
closures, (compiled or not) and functions, can all have the same type,
that is (function (...) ...), as do all applicable objects.
However, their representations have different types. The question
really boils down to whether type-of is supposed to tell you something
about the CL type lattice, or the representation of the object.
My interpretation of CLtL was that type-of returns an implementation
dependent result, in that the "precision" of the type might vary
from one interpretation to another. The "weakest" type-of would return
types of defstructs, and type t for everything else. The strongest
(and certainly unachievable) type-of would return complete function
signatures for all applicable objects, etc. In every case, what is
returned is a CL type, not the rep type.
Generics are a much harder problem, since their type signatures can
be really elaborate. I assume you mean by generics the kind of
overloaded operators you can get in Commonloops and New Flavors?
Are the implications of these for the type system understood at all?
Will CL have anything left of a type system after this kind of
overloading becomes the norm, or can we somehow salvage it?
...mike beckerle
Gold Hill Computers.
∂02-Jul-86 0915 FAHLMAN@C.CS.CMU.EDU Argument lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Jul 86 09:15:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Jul 86 12:15:34-EDT
Date: Wed, 2 Jul 1986 12:15 EDT
Message-ID: <FAHLMAN.12219495857.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: mike%gold-hill-acorn@LIVE-OAK.LCS.MIT.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: Argument lists
In-reply-to: Msg of 2 Jul 1986 12:30-EDT from mike%gold-hill-acorn at mit-live-oak.arpa
The real problem with TYPE-OF is that Common Lisp types form a lattice,
not a simple hierarchy. So in addition to implementation-dependent
decisions about how much precision to return, there are fundamental
issues about which of many possible including classes to describe.
Moon's objection is an instance of this: he loooks at one way of cutting
up the super class, while you look at a different one. None of this
bothers TYPEP or SUBTYPEP, but TYPE-OF becomes less meaningful as the
complexity of the type hierarchy increases. We nearly threw TYPE-OF out
of the language last time around, but we were persuaded that we should
keep it because it is of some use to people trying to browse around the
system. Trying to extend it and make it "do the right thing" in all
cases is a mistake.
-- Scott
∂02-Jul-86 1057 RICE@SUMEX-AIM.ARPA Types of Functions
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 2 Jul 86 10:57:47 PDT
Date: Wed 2 Jul 86 10:55:31-PDT
From: James Rice <Rice@SUMEX-AIM.ARPA>
Subject: Types of Functions
To: Common-Lisp@SU-AI.ARPA
Message-ID: <12219514065.67.RICE@SUMEX-AIM.ARPA>
Since this is being discussed now this seems a reasonable
time to ask the following :-
Why is it that in CLtL (p 76) Functionp is the only type
predicate which is not specified to be equivalent to
(typep foo 'function)?
This means that there is no guarantee that the following
will work for the obvious expansion of typecase.
(typecase foo
(function (funcall foo bar))
(otherwise (frobulate foo bar)))
It seems to me that CL should require that all implementation
dependent representation types of functions, whether they
be #<dtp-stack-closure>s or whatever, should be required to
be Subtypep of the type Function, and hence that
(typep foo 'function) should be T for such an object.
Rice
-------
∂02-Jul-86 1102 Gregor.pa@Xerox.COM Re: Portability and Code walkers
Received: from XEROX.COM by SU-AI.ARPA with TCP; 2 Jul 86 11:01:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 JUL 86 11:02:01 PDT
Date: 2 Jul 86 10:57 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Portability and Code walkers
In-reply-to: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA's message of Mon, 30
Jun 86 15:47 EST
To: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <860702-110201-4868@Xerox>
It is still (all but) impossible to write a portable code walker because
of the underspecification of the environment argument to
macroexpand(-1).
I think this problem is well understood, I just thought I would take
advantage of this opportunity to bring it up so that it would be sure to
be recorded in Scott's list of "issues to resolve".
Something like the following is needed.
There need to be constructors and accessors for the environment
structures like:
make-environment
environment-function/macro-bindings
environment-declarations
There needs to be a function like variable-globally-special-p, or
variable-special-p which takes a variable and an environment.
It would also be nice if environments had the variable bindings in them.
It may be that the accessors are not required, but the constructor is
required so that a code-walker as it walks down through an flet
(macrolet labels) can make a new environment corresponding to the scope
of the flet.
∂02-Jul-86 1214 FAHLMAN@C.CS.CMU.EDU Portability and Code walkers
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Jul 86 12:13:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Jul 86 15:12:38-EDT
Date: Wed, 2 Jul 1986 15:12 EDT
Message-ID: <FAHLMAN.12219528087.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Subject: Portability and Code walkers
In-reply-to: Msg of 30 Jun 1986 16:47-EDT from ELIOT%cs.umass.edu at CSNET-RELAY.ARPA
We might or might not be able to agree to set up an absolute restriction
against macros expanding into non-standard special forms. We could
require everyone to provide legitimate macro-expansions that are
equivalent to any non-standard special forms that the system really
uses, but whether this is useful depends on what you are using the code
walker for. You don't want to optimize or modify these equivalent forms
and then have the system bypass the whole thing.
I think that most practical solution is to provide a good extension
language for your code-walker and then add templates for any unusual
special forms present in a given system. The resulting system is not
100% portable, but the effort required to move it to a new system is
neglegible.
-- Scott
∂02-Jul-86 1352 Masinter.pa@Xerox.COM underspecified type-of
Received: from XEROX.COM by SU-AI.ARPA with TCP; 2 Jul 86 13:51:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 JUL 86 13:47:47 PDT
Date: 2 Jul 86 13:47 PDT
From: Masinter.pa@Xerox.COM
Subject: underspecified type-of
In-reply-to: mike%gold-hill-acorn%mit-live-oak:ARPA:Xerox's message of 2
Jul 86 09:13
To: common-lisp@su-ai.ARPA
Message-ID: <860702-134747-1026@Xerox>
CommonLoops gets around the underspecified nature of type-of by defining
"class-of". Class-of is defined to work for all Lisp data types, and
always returns a "class" object. While implementations may have
implementation-dependent classes (e.g., (class-of 3) may be different
than (class-of 123123123123123123)), the classes themselves observe a
well-behaved protocol, e.g., (subclassp (class-of 3) (class-named
'number)).
As you point out, "type-of" is portably useful only for structures,
since it would be valid for implementations to always return "t"
otherwise.
- - - - - -
On a side note: we had a user trying to port code from another Common
Lisp in which (he claims) it is legal to do
(defstruct env part1 part2)
(setq x (make-env))
(eq (aref x 0) 'env)
While implementations can implement structures using "arrays", isn't it
"an error" to call AREF on an instance of one? (E.g., should a "maximal
error checking" implementation always signal an error in this case?)
I've looked carefully in the defstruct section and also the section in
arrays, and I don't see anything that explicitly rules this out,
although it is clearly non-portable.
∂02-Jul-86 1415 FAHLMAN@C.CS.CMU.EDU underspecified type-of
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Jul 86 14:14:51 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Jul 86 17:06:58-EDT
Date: Wed, 2 Jul 1986 17:06 EDT
Message-ID: <FAHLMAN.12219548900.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Subject: underspecified type-of
In-reply-to: Msg of 2 Jul 1986 16:47-EDT from Masinter.pa at Xerox.COM
As you say, it is non-portable to assume that default structures are
vectors. It is currently allowed for an implementation to produce
structures that are subtypes of array, though there must be some way of
telling that they are structures as well.
Several people have suggested that we should require the default
structure type to be disjoint from array, and this is on my list of
things to discuss when the current set of issues simmers down a bit.
-- Scott
∂02-Jul-86 1512 hall@HOPKINS-EECS-BRAVO.ARPA Removal from mailing list.
Received: from HOPKINS-EECS-BRAVO.ARPA by SU-AI.ARPA with TCP; 2 Jul 86 15:12:13 PDT
Date: Wed, 2 Jul 86 16:06:14 EDT
From: Marty Hall <hall@hopkins-eecs-bravo.ARPA>
To: common-lisp@su-ai.ARPA
Subject: Removal from mailing list.
Oops! I goofed. I thought this list was kinda the Arpa equivalent of
net.lang.lisp, and my mailbox here is accumulating too many messages...
If you wouldn't mind, please remove my name from your mailing list.
Thanks!
-Marty Hall.
∂02-Jul-86 1656 FAHLMAN@C.CS.CMU.EDU Types of Functions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Jul 86 16:56:49 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Jul 86 19:56:53-EDT
Date: Wed, 2 Jul 1986 19:56 EDT
Message-ID: <FAHLMAN.12219579841.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: James Rice <Rice@SUMEX-AIM.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Types of Functions
In-reply-to: Msg of 2 Jul 1986 13:55-EDT from James Rice <Rice at SUMEX-AIM.ARPA>
Why is it that in CLtL (p 76) Functionp is the only type
predicate which is not specified to be equivalent to
(typep foo 'function)?
Good question. I don't remember, and can't think of any good reason for
this omission. Does anyone else remember what's going on here? It is
too glaringly different from the neighboring descriptions to be an
inadvertent omission. Maybe it is just the result of the confusion
about what we mean by function, which got tightened up a bit after this
section was written and needs to be tightened up still more. Once that
is done, I see no reason for Functionp not to be equivalent to Typep of
Funciton.
-- Scott
∂02-Jul-86 1737 FAHLMAN@C.CS.CMU.EDU Argument lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Jul 86 17:36:57 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Jul 86 20:34:31-EDT
Date: Wed, 2 Jul 1986 20:34 EDT
Message-ID: <FAHLMAN.12219586689.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Argument lists
In-reply-to: Msg of 1 Jul 1986 19:36-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
(In response to the Function-Parameters proposal...)
No. This does not assure adequately fast access to just the max and min
information for use in embedded interpreters. The other info might be
expensive to cons and it may be getting consed for no good reason. I feel
that either there should be two functions, or the function should be given
arguments saying kinds of info you wanted so that no time was wasted in
consing in situations where speed matters. This wouldn't be so essential
if implementations were always required to signal an error in an wrong
number of arguments situation -and- if we had the error system in place.
I expect the latter to happen in the near future, but am not so sure the
former will go through, so I really think fast access to just the numbers
part is important.
I suppose we could add Function-Parameter-Count along with
Function-Parameters. The former would return two values: min args and
max args, with the second value being NIL if there is an &rest or &key.
This is probably better than separate min and max functions, since you
normally want both values and it's faster to get both at once.
This does add clutter, however, so I would prefer not to add this
function unless we really need it. I think it is of very marginal value
for several reasons:
1. Except in the case where the function to be called takes keywords,
the difference in speed between the two calls will be very small
compared to the total cost of a call in an embedded interpreter.
2. I suspect that most implementations will return a pre-stored keyword
list rather than consing up a keyword list on the fly.
3. As you point out, the checking you would do with the
Function-Parameter-Count function is redundant with the checking that
most implementations now do, and that may be required of all
implementations (in the interpreter) if this proposal passes.
Maybe the best way to proceed is to decide now about
Function-Parameters, and for you to raise the issue of
Function-Parameter-Count (or whatever) if you still believe this is
needed after the error system and related issues are firmed up.
-- Scott
∂02-Jul-86 1752 Daniels.pa@Xerox.COM Re: underspecified type-of
Received: from XEROX.COM by SU-AI.ARPA with TCP; 2 Jul 86 17:52:22 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 JUL 86 16:59:42 PDT
Date: 2 Jul 86 16:09 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: underspecified type-of
In-reply-to: Masinter.pa's message of 2 Jul 86 13:47 PDT
To: Masinter.pa@Xerox.COM
cc: common-lisp@su-ai.ARPA
Message-ID: <860702-165942-1012@Xerox>
Seems to me that you should only be able to do that if you've declared
it as (:TYPE VECTOR).
-- Andy. --
∂02-Jul-86 1925 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Argument lists
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 2 Jul 86 19:24:51 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 34906; Wed 2-Jul-86 22:23:53 EDT
Date: Wed, 2 Jul 86 22:23 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Argument lists
To: Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12219586689.BABYL@C.CS.CMU.EDU>
Message-ID: <860702222311.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
A single function FUNCTION-PARAMETER-RANGE which returns two values is
indeed a fine idea. (I don't like -COUNT, though, because it suggests
a single return value.)
Your claim that having this function "adds clutter" is unsubstantiated
in my mind. The function is simple, well-defined, and useful to a
definable subset of people. MACSYMA already had such a thing which was
implemented by some of the grungiest system-dependent code you could
imagine.
If you think it duplicates functionality with this other function,
it's probably because your view of functionality is too intimately tied
to data flow. Some functions want part of their contract to be that
they are fast. If you overgeneralize their return values, as I claim
is happening here, you add "data flow" functionality, but you may end
up forcing some implementations to be slow on an operation that they
didn't need to be slow at, or you may force some implementations to
have to do a radical redesign of their storage technique for arglists
in order to achieve the required speed. I'd just as soon we didn't force
such redesigns for reasons like this where we can so trivially keep
from doing this.
By the way, of the implementations which cache a constant list, I wonder
how many of them cache a list containing the &AUX spec. I hope we will
make it explicit that &AUX specs should not be visible in the list returned
by ARGLIST. They are not part of the external interface and my experience
is that I always end up writing the same idiom, namely:
(LET ((AUXL (MEMBER '&AUX ARGL))) (IF AUXL (LDIFF ARGL AUXL) ARGL))
I've done this enough times in destructuring LAMBDA lists myself that
I'd just as soon it were done for me now that we're talking about having
a system supplied tool for extracting arglists. However, I wouldn't want
my FUNCTION-PARAMETER-RANGE function to have to wait for the MEMBER and
LDIFF if I was just going to throw away the result anyway.
Anyway, the real point is that it's not fair for you to make claims about
comparative speeds or even about things probably being fast unless you
have the data to back up such claims. My experience with trying to write
portable CL programs thus far suggests that the only thing you can depend
on are things that are unambiguously specified in CLtL; if something is
not specified, it may vary widely. Speed is certainly no exception.
With regard to your suggestion that the best way to proceed is to hope
that we reach closure on the issue of argument checking, I don't think
that's a good idea. I see no obvious reason for near-term concensus on
that issue and would prefer to assume that FUNCTION-PARAMETER-RANGE
will go in unless I'm pleasantly surprised, rather than vice versa.
Also, resolution of that issue won't be adequate for my purposes unless
number-of-argument checking is required in both interpreted and compiled
code.
By the way, everyone keeps making vague allusions to the new condition
system as if it could somehow solve the issue of argument checking. You
shouldn't hope for magical cures from my camp. The condition system only
says what happens after you signal an error. It doesn't get involved at
all in the decision of when to signal and when not to. The issue of
whether to do number of argument checking (or any other kind of error
checking) is only peripherally related to the issue of how errors which
result from such checks are to be signalled/corrected.
∂02-Jul-86 1946 FAHLMAN@C.CS.CMU.EDU Argument lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Jul 86 19:46:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Jul 86 22:46:06-EDT
Date: Wed, 2 Jul 1986 22:46 EDT
Message-ID: <FAHLMAN.12219610643.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Argument lists
In-reply-to: Msg of 2 Jul 1986 22:23-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
Nobody has ever accused me of consorting with dataflow ideas before. I
guess one needs a thick skin to make it in this job...
I'm still not convinced that speed is of critical importance here, but
it is clear to me that your perception of the need for this possibly
faster way of getting parameter info is stronger than my desire to
reduce the number of functions by one. Maybe you're right. I give up.
Revised proposal:
Let's add both FUNCTION-PARAMETERS and FUNCTION-PARAMETER-RANGE.
Can anybody not live with THAT?
-- Scott
∂02-Jul-86 1958 FAHLMAN@C.CS.CMU.EDU Argument lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 Jul 86 19:57:31 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Jul 86 22:57:06-EDT
Date: Wed, 2 Jul 1986 22:57 EDT
Message-ID: <FAHLMAN.12219612639.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Argument lists
In-reply-to: Msg of 2 Jul 1986 22:23-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
...I hope we will
make it explicit that &AUX specs should not be visible in the list returned
by ARGLIST.
*IF* we add ARGLIST to the spec. There seems to be very little
enthusiasm for adding ARGLIST in raw form.
By the way, everyone keeps making vague allusions to the new condition
system as if it could somehow solve the issue of argument checking. You
shouldn't hope for magical cures from my camp.
Well, once we've decided on an error system in general, then we have to
decide what kind of error we signal for various problems, such as "too
many/few args", and what information has to be passed to the handler.
This is what people are waiting to see. You may not plan to make
proposals in this area, but your error proposal is a prerequisite for
discussing the signalling of specific errors in details. Nobody expects
a magical way of detecting errors at no cost, but the amount of stuff
that must be included in the signal certainly influences the cost of
requiring certain checks.
-- Scott
∂02-Jul-86 2311 NGALL@G.BBN.COM Re: Types of Functions
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 2 Jul 86 23:10:15 PDT
Date: 3 Jul 1986 02:09-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Types of Functions
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: Rice@SUMEX-AIM.ARPA, Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 3-Jul-86 02:09:58.NGALL>
In-Reply-To: <FAHLMAN.12219579841.BABYL@C.CS.CMU.EDU>
Date: Wed, 2 Jul 1986 19:56 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: James Rice <Rice@SUMEX-AIM.ARPA>
Subject: Types of Functions
In-Reply-To: Msg of 2 Jul 1986 13:55-EDT from James Rice <Rice at SUMEX-AIM.ARPA>
Message-ID: <FAHLMAN.12219579841.BABYL@C.CS.CMU.EDU>
Why is it that in CLtL (p 76) Functionp is the only type
predicate which is not specified to be equivalent to
(typep foo 'function)?
Good question. I don't remember, and can't think of any good reason for
this omission. Does anyone else remember what's going on here? It is
too glaringly different from the neighboring descriptions to be an
inadvertent omission. Maybe it is just the result of the confusion
about what we mean by function, which got tightened up a bit after this
section was written and needs to be tightened up still more. Once that
is done, I see no reason for Functionp not to be equivalent to Typep of
Funciton.
-- Scott
--------------------
(typep foo 'function) causes an error to be signalled according to
page 47. Perhaps that is why functionp is not defined in terms of it?
:-)
-- Nick
∂02-Jul-86 2330 NGALL@G.BBN.COM Re: Argument lists
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 2 Jul 86 23:30:04 PDT
Date: 3 Jul 1986 02:29-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Argument lists
From: NGALL@G.BBN.COM
To: KMP@SCRC-STONY-BROOK.ARPA
Cc: Fahlman@C.CS.CMU.EDU, Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 3-Jul-86 02:29:33.NGALL>
In-Reply-To: <860702222311.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 2 Jul 86 22:23 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
To: Fahlman@CMU-CS-C.ARPA
Subject: Argument lists
In-Reply-To: <FAHLMAN.12219586689.BABYL@C.CS.CMU.EDU>
Message-ID: <860702222311.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
A single function FUNCTION-PARAMETER-RANGE which returns two values is
indeed a fine idea. (I don't like -COUNT, though, because it suggests
a single return value.)
Your claim that having this function "adds clutter" is unsubstantiated
in my mind. The function is simple, well-defined, and useful to a
definable subset of people. MACSYMA already had such a thing which was
implemented by some of the grungiest system-dependent code you could
imagine.
If you think it duplicates functionality with this other function,
it's probably because your view of functionality is too intimately tied
to data flow. Some functions want part of their contract to be that
they are fast. If you overgeneralize their return values, as I claim
is happening here, you add "data flow" functionality, but you may end
up forcing some implementations to be slow on an operation that they
didn't need to be slow at, or you may force some implementations to
have to do a radical redesign of their storage technique for arglists
in order to achieve the required speed. I'd just as soon we didn't force
such redesigns for reasons like this where we can so trivially keep
from doing this.
Out of curiosity, why do you feel the need for a 'fast' version of
function-parameters? I got the feeling that most people thought that
it would not be used in time-critical code. If it is not going to be
used in tight-loops, do we really need the separate 'speed'
functionality?
Also, I would be interested to hear from any implementor (preferably
the one who would be responsible for implementing FUNCTION-PARAMETERS
and FUNCTION-PARAMETER-RANGE) who thinks they would implement
FUNCTION-PARAMETERS in such a way as to make it, say, an order of
magnitude slower.
Anyway, if it comes to a vote and if I had a vote, I would vote
against adding FUNCTION-PARAMETER-RANGE.
-- Nick
∂03-Jul-86 0013 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Speed of FUNCTION-PARAMETER-RANGE
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 3 Jul 86 00:13:29 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 34985; Thu 3-Jul-86 03:12:49 EDT
Date: Thu, 3 Jul 86 03:12 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Speed of FUNCTION-PARAMETER-RANGE
To: NGALL@G.BBN.COM
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM] 3-Jul-86 02:29:33.NGALL>
References: <860702222311.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <860703031210.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 3 Jul 1986 02:29-EDT
From: NGALL@G.BBN.COM
Out of curiosity, why do you feel the need for a 'fast' version of
function-parameters? I got the feeling that most people thought that
it would not be used in time-critical code.
Most people thought that. I guess they were wrong. I have counterexamples.
If it is not going to be used in tight-loops, do we really need the
separate 'speed' functionality?
Yes. In embedded languages which use their own interpreters rather than
calling EVAL (eg, Macsyma, Scheme, ...), you may wish to enforce
number-of-args checking even if the implementation you are running is
does not.
Also, Macsyma has a situation where it's been asked to defer the
application of certain kinds of functions and just return what we call a
noun form. ie, (SIN X) where X is 3 might yield the symbolic expression
(SIN 3) rather a numeric approximation such as 0.14112002 . There's a
command that later asks Macsyma to go through and evaluate nounds.
Even though the function for a noun doesn't get applied at the time the
rest of an expression is being evaluated, it may be desirable at the
interpreter to go ahead and do a preliminary check for correct number
of arguments.
Both of these situations want to be very fast because they occur in MEVAL,
the Macsyma analog of EVAL, and can consequently happen quite often.
If you or anyone else has further queries, I'll gladly answer them, but
I suggest we carry them on in private mail. I think I've made my point
and my guess is that most readers are tired of this line of discussion
by now.
∂03-Jul-86 0226 DESMEDT%HNYKUN52.BITNET@WISCVM.ARPA withdrawal from mailing list
Received: from WISCVM.WISC.EDU by SU-AI.ARPA with TCP; 3 Jul 86 02:25:59 PDT
Received: from (DESMEDT)HNYKUN52.BITNET by WISCVM.ARPA on 07/03/86 at
04:26:13 CDT
Date: Thu, 3 Jul 86 10:52 N
From: <DESMEDT%HNYKUN52.BITNET@WISCVM.ARPA>
Subject: withdrawal from mailing list
To: common-lisp@su-ai.arpa
X-Original-To: common-lisp@su-ai.arpa
Please remove my name from this mailing list. My only real interest is in
object-oriented extensions of Common LISP. If there happens to be a
separate discussion group dedicated to this topic, please let me know.
Koenraad De Smedt
∂03-Jul-86 0608 @MIT-LIVE-OAK.ARPA:JerryB@GOLD-HILL-ACORN.LCS.MIT.EDU Speed of FUNCTION-PARAMETER-RANGE
Received: from LIVE-OAK.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jul 86 06:08:06 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3618; 3 Jul 86 09:10:26-EDT
Received: from VENEZUELA.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 27113; Thu 3-Jul-86 08:58:37-EDT
Date: Thu, 3 Jul 86 08:56 EST
From: JerryB@a
To: KMP@SCRC-STONY-BROOK.ARPA
Subject: Speed of FUNCTION-PARAMETER-RANGE
Cc: NGALL@G.BBN.COM, COMMON-LISP@SU-AI.ARPA
Date: Thu, 3 Jul 86 03:12 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Date: 3 Jul 1986 02:29-EDT
From: NGALL@G.BBN.COM
Out of curiosity, why do you feel the need for a 'fast' version of
function-parameters? I got the feeling that most people thought that
it would not be used in time-critical code.
Most people thought that. I guess they were wrong. I have counterexamples.
I agree with KMP, that a fast version is necessary to determine just the
min and max number of parameters a function takes.
∂03-Jul-86 0619 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Re: Types of Functions
Received: from LIVE-OAK.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jul 86 06:19:34 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3620; 3 Jul 86 09:21:40-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 27118; Thu 3-Jul-86 09:21:34-EDT
Date: Thu, 3 Jul 86 09:18 EST
From: mike@a
To: NGALL@G.BBN.COM
Subject: Re: Types of Functions
Cc: Fahlman@C.CS.CMU.EDU, Rice@SUMEX-AIM.ARPA, Common-Lisp@SU-AI.ARPA
Date: 3 Jul 1986 02:09-EDT
From: NGALL@G.BBN.COM
Why is it that in CLtL (p 76) Functionp is the only type
predicate which is not specified to be equivalent to
(typep foo 'function)?
--------------------
(typep foo 'function) causes an error to be signalled according to
page 47. Perhaps that is why functionp is not defined in terms of it?
:-)
-- Nick
On pg. 47, the spec states that type SIGNATURES cannot be used to
discriminate types. However, the type "function" is not a signature.
Clearly (typep foo '(function (...) ...)) shouldn't be allowed
since it is obvious that one cannot decide it, or even try to decide it
in any reasonable way.
For example (typep foo (satisfies #'my-type-predicate)) is reasonable
since one can at least run the satisfies function on the object "foo".
But in (typep foo '(function ((satisfies #'my-type-predicate)) t))),
there is absolutely no way to know, and nothing to try to run to find out.
However, there is no reason why (typep foo 'function) should cause any
problems. It should be equivalent to (functionp foo).
∂03-Jul-86 0624 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Re: Types of Functions
Received: from LIVE-OAK.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jul 86 06:24:10 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3621; 3 Jul 86 09:26:37-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 27120; Thu 3-Jul-86 09:26:06-EDT
Date: Thu, 3 Jul 86 09:23 EST
Sender: mike@a
To: NGALL@G.BBN.COM
From: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: Re: Types of Functions
Cc: Fahlman@C.CS.CMU.EDU, Rice@SUMEX-AIM.ARPA, Common-Lisp@SU-AI.ARPA
...brain damaged mail program strikes again,.. and I forgot to
sign my reply. You'll notice that the from field of my last note
contains only mike@a, to which you cannot reply.
I am:
mike beckerle
Gold Hill Computers
send replies to: mike%gold-hill-acorn@mit-live-oak.arpa
∂03-Jul-86 0630 FAHLMAN@C.CS.CMU.EDU Types of Functions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Jul 86 06:30:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 3 Jul 86 09:17:50-EDT
Date: Thu, 3 Jul 1986 09:17 EDT
Message-ID: <FAHLMAN.12219725627.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Subject: Types of Functions
In-reply-to: Msg of 3 Jul 1986 02:09-EDT from NGALL at G.BBN.COM
(typep foo 'function) causes an error to be signalled according to
page 47. Perhaps that is why functionp is not defined in terms of it?
:-)
I'm not sure what the scope of your :-) keyword is meant to be (this is
not defined in the current spec), but I have always read the passage on
page 47 as outlawing Typep on the complex list form of the Function
type-specifier. The wording here is ambiguous about whether the simple
form, (typep foo 'function), is legal, and I see no reason for this not
to be legal. I guess this is another thing we need to clarify.
-- Scott
∂03-Jul-86 0841 snyder%hplsny@hplabs.HP.COM Re: Argument lists
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 3 Jul 86 08:41:25 PDT
Received: from hplsny by hplabs.HP.COM ; Thu, 3 Jul 86 08:39:46 pdt
Received: by hplsny ; Thu, 3 Jul 86 08:39:28 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8607031539.AA03068@hplsny>
Date: Thursday, July 3, 1986 08:39:19
Subject: Re: Argument lists
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 2-Jul-86 22:46:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
I'm still not convinced that speed is of critical importance here, but
it is clear to me that your perception of the need for this possibly
faster way of getting parameter info is stronger than my desire to
reduce the number of functions by one. Maybe you're right. I give up.
Revised proposal:
Let's add both FUNCTION-PARAMETERS and FUNCTION-PARAMETER-RANGE.
Can anybody not live with THAT?
-- Scott
Sorry, I tried, but I can't resist...
Isn't the proper "Common Lisp" solution to this issue to say that the compiler
ought to recognize calls to FUNCTION-PARAMETERS that only use the first two
values and, in implementations where FUNCTION-PARAMETER-RANGE would be faster,
convert those calls to calls on SYS:FUNCTION-PARAMETER-RANGE (now an internal
function)?
Alan
-------
∂03-Jul-86 1417 masinter.pa@Xerox.COM Re: Types of Functions
Received: from XEROX.COM by SU-AI.ARPA with TCP; 3 Jul 86 14:16:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 03 JUL 86 14:16:05 PDT
Date: 3 Jul 86 14:15 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Types of Functions
In-reply-to: Fahlman%C.CS.CMU:EDU:Xerox's message of 2 Jul 86 17:32
To: Common-Lisp@su-ai.ARPA
Message-ID: <860703-141605-1874@Xerox>
The problem is that the "function" types isn't a very good member of the
type lattice. For example, "functionp" is true of lists whose car is
lambda.
In this case, "functionp" is a much more dynamic property. With most
data types,
(typecase x
(regulartype ... compute ... use x ... ))
the "use x" can assume that x is still "regulartype". This is currently
true of all types except those defined with "satisfies". In this
example, if "compute" were to (setf (car x) 'not-lambda), functionp
would no longer be true.
Given the existence of "satisfies" type specifiers,
(deftype function () '(satisfies functionp))
Note also that symbols satisfy "functionp". ("functionp is always true
of symbols, lists whose car is the symbol lambda, any value returned by
the function special form, and any values returned by the function
compile... ").
This is dangerous to those who might write
(typecase foo
(function ...)
(symbol ...)
...)
Finally, it is an implementation dependent type like "fixnum", whose use
is discouraged. Functions aren't a first-class type in Common Lisp, and
wishing it so (or allowing 'function in a typep) won't make it so.
∂05-Jul-86 1654 Pavel.pa@Xerox.COM DECLARE SPECIAL Considered Confusing
Received: from XEROX.COM by SU-AI.ARPA with TCP; 5 Jul 86 16:54:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 86 16:54:24 PDT
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
Subject: DECLARE SPECIAL Considered Confusing
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860705-165424-2715@Xerox>
I have a question concerning some ambiguity in the description of the
scope of a special declaration inside a LET. Consider this code:
(setq foo 6)
(let ((foo 7))
(let ((foo (1+ foo)))
(declare (special foo))
foo))
Both Symbolics and CLISP return 8 for this, but VAXLISP returns 7.
Clearly, the question is whether or not the special declaration covers
the init-form of the enclosing LET or just the bindings themselves.
According to the ``nonsense'' example in CLtL, page 155, the reference
to ``foo'' in the call to 1+ should be special. The GLS clarification
for page 159, however, seems to support a different philosophy:
``(*) 159 Clarify that in the following example
(defun foo (x)
(declare (inline bar))
(bar x) ; first
(flet ((bar (z) (bar (+ z 1)))) ; second
(bar x)) ; third
(bar x) ; fourth
the first, second and fourth calls to BAR are affected by the INLINE
declaration, but not the third one.''
This seems to support the view that the init-form of a binding is in a
scope outside of that of the binding itself and the body of the LET (or
FLET or ...). I prefer this view.
I would like to propose the following rule for the scope of declarations
in binding forms:
``A declaration in a binding form (such as LET) affects the body of the
form and the bindings themselves. It does not affect the init-forms for
the bindings; they are in the same scope as the binding form as a
whole.''
This rule has the advantage (over the rule given for the nonsense
example) that the scope of the declarations is the same as the scope of
the bindings. Thus, for the nonsense example:
(defun nonsense (k x z)
(foo z x) ;First call to foo
(let ((j (foo k x)) ;Second call to foo
(x (* k k)))
(declare (inline foo)
(special x z))
(foo x j z))) ;Third call to foo
the inline declaration affects only the third call to foo (not the
second) and only the references to x and z in the third call to foo are
special (not the reference to x in the second call).
There would be only two exceptions to this rule:
-- In a LABELS binding, references in the definitions of the functions
to the very functions being bound would be affected by any declarations
affecting the bindings themselves. This makes sense because of the
recursive quality of the binding.
-- The PROCLAIM function establishes pervasive declarations, covering
all bindings of and references to the symbols named. Such declarations
can, of course, be countermanded by local declarations or later
proclamations.
What do people think? It would appear that some implementations already
work this way.
Pavel Curtis
Xerox AIS
∂06-Jul-86 1112 DCP@QUABBIN.SCRC.Symbolics.COM subst-if-not and nsubst-if-not, programming folk-lore
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 6 Jul 86 11:12:31 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14598; Sun 29-Jun-86 19:42:30 EDT
Date: Sun, 29 Jun 86 19:42 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: subst-if-not and nsubst-if-not, programming folk-lore
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860629194244.5.DCP@FIREBIRD.SCRC.Symbolics.COM>
These are really neat functions, and counterintuitive to boot. One of
our documentation people tried this:
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (subst-if '3.1415 #'numberp item-list)))
(values new item-list))
=> (NUMBERS (3.1415 3.1415 3.1415) SYMBOLS (FOO BAR))
(NUMBERS (1.0 2 5/3) SYMBOLS (FOO BAR))
which is correct, numbers were substituted. Similarly, nsubst-if works
as expected:
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (nsubst-if '3.1415 #'numberp item-list)))
(values new item-list))
=> (NUMBERS (3.1415 3.1415 3.1415) SYMBOLS (FOO BAR))
(NUMBERS (3.1415 3.1415 3.1415) SYMBOLS (FOO BAR))
Now, when one tries subst-if-not, one gets a small surprise until one
thinks about it a bit:
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (subst-if-not '3.1415 #'numberp item-list)))
(values new item-list))
=> 3.1415
(NUMBERS (1.0 2 5/3) SYMBOLS (FOO BAR))
and nsubst-if-not gives the same thing
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (nsubst-if-not '3.1415 #'numberp item-list)))
(values new item-list))
=> 3.1415
(NUMBERS (1.0 2 5/3) SYMBOLS (FOO BAR))
, i.e., the list is NOT destructed. A careful reading explains why: the
item-list is indeed not a number, and therefore it gets substituted (but
you can't substitute the entire list, so you don't modify it).
What the person probably wanted is to replace the non-null atomic
leafs. I'm not sure what to think. One thing I'm thinking is that
(n)subst-if-not is too counter-intuitive to be worth having in the
language, even for completeness. At the very list, I think the
book/manual should carefully discuss this issue to people don't get
confused for years.
∂06-Jul-86 1113 DCP@QUABBIN.SCRC.Symbolics.COM Two functions for everything?
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 6 Jul 86 11:13:05 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14719; Mon 30-Jun-86 11:54:52 EDT
Date: Mon, 30 Jun 86 11:55 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Two functions for everything?
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <12218956472.19.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860630115511.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon 30 Jun 86 08:52:34-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
From: DCP@QUABBIN.SCRC.Symbolics.COM (David C. Plummer)
This is bogus folks. All you need is two entrypoints: one which doesn't
check anything, and one which checks what it needs to. They then join.
Safety 0 (at compile time) causes functions to call the the
don't-check-anything entrypoint, and safety > 0 causes functions to call
the one that checks. Hell, you could have a different entrypoint for
each setting of safety.
Yeah, but where in CLtL do we provide a way to make functions with multiple
entry points? I certainly don't want to have to hand-code every single
function that does optional error checking in assembly language (or
whatever). The point I was trying to make was that, if we are serious
about making multiple levels of error checking part of the language, we
should also provide some high-level constructs for specifying what error
checking goes on when. Multiple entry points would be one way to implement
such a construct....
Why do you think CLtL has to specify how this is done? It is completely
in the domain of the implementation of the compiler, the linker and the
compiled function format. The only thing CLtL needs to specify is how
to get what you want, and I think it already has that with the safety
setting.
∂06-Jul-86 1152 @UR-ACORN.ARPA,@UR-BEECHNUT.ARPA:miller@UR-ACORN.ARPA subst-if-not and nsubst-if-not, programming folk-lore
Received: from UR-ACORN.ARPA by SU-AI.ARPA with TCP; 6 Jul 86 11:51:52 PDT
Received: from UR-BEECHNUT.ARPA by UR-ACORN.ARPA via INTERNET with SMTP id 30083; 6 Jul 86 14:47:48-EDT
Date: Sun, 6 Jul 86 14:48 EDT
From: Brad Miller <miller@UR-ACORN.ARPA>
Subject: subst-if-not and nsubst-if-not, programming folk-lore
To: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: Common-Lisp@SU-AI.ARPA
Fcc: ACORN:>miller>mail>mailout.file
In-Reply-To: <860629194244.5.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860706144822.2.MILLER@UR-BEECHNUT.ARPA>
Date: Sun, 29 Jun 86 19:42 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
These are really neat functions, and counterintuitive to boot. One of
our documentation people tried this:
[...]
Now, when one tries subst-if-not, one gets a small surprise
until one thinks about it a bit:
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (subst-if-not '3.1415 #'numberp item-list)))
(values new item-list))
=> 3.1415
(NUMBERS (1.0 2 5/3) SYMBOLS (FOO BAR))
and nsubst-if-not gives the same thing
[...]
, i.e., the list is NOT destructed. A careful reading explains why: the
item-list is indeed not a number, and therefore it gets substituted (but
you can't substitute the entire list, so you don't modify it).
What the person probably wanted is to replace the non-null atomic
leafs. I'm not sure what to think. One thing I'm thinking is that
(n)subst-if-not is too counter-intuitive to be worth having in the
language, even for completeness. At the very list, I think the
book/manual should carefully discuss this issue to people don't get
confused for years.
Good point. To point out the obvious: perhaps [n]subst-if-not should not
try to match subtrees? (which would include nil cdrs).....
That would still give a useful function on leaves.... Your example would
have been evaluated to:
(3.1415 (1.0 2 5/3) 3.1415 (3.1415 3.1415))
which is a bit more intuitive, I think, though not precisely an inverse
to subst-if, which as you suggested, can be quite non-intuitive (and
perhaps unnecessary)....
Brad Miller
miller@rochester.arpa
miller@ur-acorn.arpa
∂06-Jul-86 1501 RPG Object-Oriented Programming Meeting at L&FP
To: common-lisp@SU-AI.ARPA
There will be a meeting on the topic of Object-Oriented Programming right
after the Lisp and Functional Programming Conference. The date is
Wednesday, August 6, at 2pm, in a room to be announced.
This audience might also be interested in the panel session, chaired
by Peter Deutsch, on Object-Oriented Programming, to be held from
3:45pm until 5:45pm on Tuesday, August 5, at the Lisp Conference.
The distinguished panel includes these folks:
Danny Bobrow, Xerox PARC
Gary Drescher, MIT
David Moon, Symbolics
Alan Snyder, HP
-rpg-
∂07-Jul-86 0704 DCP@QUABBIN.SCRC.Symbolics.COM DECLARE SPECIAL Considered Confusing
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 7 Jul 86 07:04:50 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 16663; Mon 7-Jul-86 10:03:32 EDT
Date: Mon, 7 Jul 86 10:03 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: DECLARE SPECIAL Considered Confusing
To: Pavel.pa@Xerox.COM, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860705-165424-2715@Xerox>
Message-ID: <860707100308.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
What do people think? It would appear that some implementations already
work this way.
I agree. Consider LET to be a macro that turns into LAMBDA:
(let ((foo (1+ foo)))
(declare (special foo))
foo)
=> ((lambda (foo)
(declare (special foo))
foo)
(1+ foo))
[I think this is what MacLisp actually did (does?).] The scoping here
is clear: the foo in (1+ foo) is outside the scope of the declaration.
∂07-Jul-86 0708 gls@Think.COM Re: Argument lists: a proposal to shoot at
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 7 Jul 86 07:08:34 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Mon, 7 Jul 86 10:08:44 edt
Date: Mon, 7 Jul 86 10:09 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: Argument lists: a proposal to shoot at
To: masinter.pa@Xerox.COM
Cc: gls@AQUINAS, common-lisp@SU-AI.ARPA
In-Reply-To: <860703-170554-2046@Xerox>
Message-Id: <860707100936.1.GLS@BOETHIUS.THINK.COM>
Date: 3 Jul 86 17:04 PDT
From: masinter.pa@Xerox.COM
if min and max were like start and end, the "max" would be exclusive, not inclusive.
That is correct, and if I were to press my proposal further
I would adopt that change.
--Guy
∂07-Jul-86 0712 alatto@BBNCC5.ARPA Re: subst-if-not and nsubst-if-not, programming folk-lore
Received: from BBNCC5.ARPA by SU-AI.ARPA with TCP; 7 Jul 86 07:11:51 PDT
To: Brad Miller <miller@ur-acorn.ARPA>
cc: "David C. Plummer" <DCP@scrc-quabbin.ARPA>, Common-Lisp@su-ai.ARPA
Subject: Re: subst-if-not and nsubst-if-not, programming folk-lore
In-reply-to: Your message of Sun, 6 Jul 86 14:48 EDT.
<860706144822.2.MILLER@UR-BEECHNUT.ARPA>
Date: 07 Jul 86 10:04:29 EDT (Mon)
From: Andy Latto <alatto@BBNCC5.ARPA>
Date: Sun, 29 Jun 86 19:42 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
These are really neat functions, and counterintuitive to boot.
[...]
Now, when one tries subst-if-not, one gets a small surprise
until one thinks about it a bit:
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (subst-if-not '3.1415 #'numberp item-list)))
(values new item-list))
=> 3.1415
(NUMBERS (1.0 2 5/3) SYMBOLS (FOO BAR))
and nsubst-if-not gives the same thing
[...]
, i.e., the list is NOT destructed. A careful reading explains why: the
item-list is indeed not a number, and therefore it gets substituted (but
you can't substitute the entire list, so you don't modify it).
[...]
Good point. To point out the obvious: perhaps [n]subst-if-not should not
try to match subtrees? (which would include nil cdrs).....
That would still give a useful function on leaves.... Your example would
have been evaluated to:
(3.1415 (1.0 2 5/3) 3.1415 (3.1415 3.1415))
which is a bit more intuitive, I think, though not precisely an inverse
to subst-if, which as you suggested, can be quite non-intuitive (and
perhaps unnecessary)....
Brad Miller
miller@rochester.arpa
miller@ur-acorn.arpa
I think this would be a bad idea. Consistency is important. Everywhere else
that there are two functions that differ only by a -not in the name of
one, the only difference in the semantics is to reverse the test. This is
as it should be.
Conceptually, there are four possible subst-if-like functions, depending on
whether the the test is positive or negative and whether the substitution applies
to subtrees or only to leaves. These could have names like subst-if, subst-if-not,
leaf-subst, and leaf-subst-if-not. If you think that the only two of these
worthy of being part of common lisp are subst-if and leaf-subst-if-not, I
would disagree with you, but not strongly. If you think that these functions
should exist under the names subst-if and subst-if-not, and everyone should
remember that -not automatically implies leaf-, I would disagree with you
strongly.
leaf-subst-if and its relatives might be useful, but they're easy
to simulate with test functions like
(lambda (foo) (and (atom foo) (whatever foo))),
though this would match nil cdr's. Do we really need them?
Andy Latto
alatto@bbn.arpa
∂07-Jul-86 0713 DCP@QUABBIN.SCRC.Symbolics.COM subst-if-not and nsubst-if-not, programming folk-lore
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 7 Jul 86 07:13:17 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 16667; Mon 7-Jul-86 10:11:21 EDT
Date: Mon, 7 Jul 86 10:10 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: subst-if-not and nsubst-if-not, programming folk-lore
To: Brad Miller <miller@UR-ACORN.ARPA>,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860706144822.2.MILLER@UR-BEECHNUT.ARPA>
Message-ID: <860707101058.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sun, 6 Jul 86 14:48 EDT
From: Brad Miller <miller@UR-ACORN.ARPA>
Date: Sun, 29 Jun 86 19:42 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
These are really neat functions, and counterintuitive to boot. One of
our documentation people tried this:
[...]
Now, when one tries subst-if-not, one gets a small surprise
until one thinks about it a bit:
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (subst-if-not '3.1415 #'numberp item-list)))
(values new item-list))
=> 3.1415
(NUMBERS (1.0 2 5/3) SYMBOLS (FOO BAR))
and nsubst-if-not gives the same thing
[...]
, i.e., the list is NOT destructed. A careful reading explains why: the
item-list is indeed not a number, and therefore it gets substituted (but
you can't substitute the entire list, so you don't modify it).
What the person probably wanted is to replace the non-null atomic
leafs. I'm not sure what to think. One thing I'm thinking is that
(n)subst-if-not is too counter-intuitive to be worth having in the
language, even for completeness. At the very list, I think the
book/manual should carefully discuss this issue to people don't get
confused for years.
Good point. To point out the obvious: perhaps [n]subst-if-not should not
try to match subtrees? (which would include nil cdrs).....
That would still give a useful function on leaves.... Your example would
have been evaluated to:
(3.1415 (1.0 2 5/3) 3.1415 (3.1415 3.1415))
which is a bit more intuitive, I think, though not precisely an inverse
to subst-if, which as you suggested, can be quite non-intuitive (and
perhaps unnecessary)....
No, I think if [n]subst-if-not stay in the language then their
definitions should not change. Conses are just as valid as any other
data, and changing their definition could make them even more confusing.
I'm not (currently) advocating removing them from the language. I am
advocating documenting this pitfall. It may want to say that "we"
currently believe code is easier to write, undersetand and maintain if
[n]subst-if is used intead of [n]subst-if-not and give the example
(nsubst-if 3.1415 #'(lambda (item)
(and item
(atom item)
(not (numberp item))))
item-list)
The screw here is that NIL in the CAR isn't distinguished from NIL in
the CDR, which may be a more fundamental problem. Doing the CDR, even
though it may be NIL has several valid applications, so it shouldn't be
dismissed lightly.
∂07-Jul-86 0730 gls@Think.COM subst-if-not and nsubst-if-not, programming folk-lore
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 7 Jul 86 07:29:54 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Mon, 7 Jul 86 10:29:57 edt
Date: Mon, 7 Jul 86 10:30 EDT
From: Guy Steele <gls@Think.COM>
Subject: subst-if-not and nsubst-if-not, programming folk-lore
To: DCP@QUABBIN.SCRC.Symbolics.COM, Common-Lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860629194244.5.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-Id: <860707103053.5.GLS@BOETHIUS.THINK.COM>
Date: Sun, 29 Jun 86 19:42 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
...
Now, when one tries subst-if-not, one gets a small surprise until one
thinks about it a bit:
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (subst-if-not '3.1415 #'numberp item-list)))
(values new item-list))
=> 3.1415
(NUMBERS (1.0 2 5/3) SYMBOLS (FOO BAR))
How about
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (subst-if-not '3.1415
#'(lambda (x) (or (numberp x) (listp x)))
item-list)))
(values new item-list))
?
[I tried to test this, but there appears to be a trivial bug in the
Symbolics 3600 release 6.1 implementation of SUBST-IF-NOT.]
What the person probably wanted is to replace the non-null atomic
leafs. I'm not sure what to think. One thing I'm thinking is that
(n)subst-if-not is too counter-intuitive to be worth having in the
language, even for completeness. At the very list, I think the
book/manual should carefully discuss this issue to people don't get
confused for years.
At the very LIST, you say?
--Guy
∂07-Jul-86 0810 DCP@QUABBIN.SCRC.Symbolics.COM subst-if-not and nsubst-if-not, programming folk-lore
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 7 Jul 86 08:10:24 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 16715; Mon 7-Jul-86 11:08:59 EDT
Date: Mon, 7 Jul 86 11:08 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: subst-if-not and nsubst-if-not, programming folk-lore
To: Guy Steele <gls@Think.COM>, DCP@QUABBIN.SCRC.Symbolics.COM,
Common-Lisp@SU-AI.ARPA
In-Reply-To: <860707103053.5.GLS@BOETHIUS.THINK.COM>
Message-ID: <860707110827.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon, 7 Jul 86 10:30 EDT
From: Guy Steele <gls@Think.COM>
Date: Sun, 29 Jun 86 19:42 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
...
Now, when one tries subst-if-not, one gets a small surprise until one
thinks about it a bit:
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (subst-if-not '3.1415 #'numberp item-list)))
(values new item-list))
=> 3.1415
(NUMBERS (1.0 2 5/3) SYMBOLS (FOO BAR))
How about
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (subst-if-not '3.1415
#'(lambda (x) (or (numberp x) (listp x)))
item-list)))
(values new item-list))
?
Sure, we can all find the right solution once we see the pitfall. My
point is to document the pitfall so people are less surprised when it
happens to them.
[I tried to test this, but there appears to be a trivial bug in the
Symbolics 3600 release 6.1 implementation of SUBST-IF-NOT.]
[Recently fixed. Somebody should write a program to analyze mail coming
out of vendors to track what areas of the software system the vendors
are working on...]
What the person probably wanted is to replace the non-null atomic
leafs. I'm not sure what to think. One thing I'm thinking is that
(n)subst-if-not is too counter-intuitive to be worth having in the
language, even for completeness. At the very list, I think the
book/manual should carefully discuss this issue to people don't get
confused for years.
At the very LIST, you say?
So I did. A recent typo I made was "If you are trying to confuse me,
you are goind a good job."
--Guy
--
∂07-Jul-86 1015 Masinter.pa@Xerox.COM Re: subst-if-not and nsubst-if-not, programming folk-lore
Received: from XEROX.COM by SU-AI.ARPA with TCP; 7 Jul 86 10:15:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JUL 86 10:15:26 PDT
Date: 7 Jul 86 10:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: subst-if-not and nsubst-if-not, programming folk-lore
In-reply-to: Guy Steele <gls@Think.COM>'s message of Mon, 7 Jul 86 10:30
EDT
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860707-101526-3291@Xerox>
Sounds like people want the equivalent of Interlisp's SUBST:
(SUBST NEW OLD EXPR) [Function]
Returns the result of substituting NEW for all occurrences of OLD in the
expression EXPR. Substitution occurs whenever OLD is EQUAL to CAR of
some subexpression of EXPR, or when OLD is atomic and EQ to a non-NIL
CDR of some subexpression of EXPR. For example:
(SUBST 'A 'B '(C B (X . B))) => (C A (X . A))
(SUBST 'A '(B C) '((B C) D B C))
=> (A D B C) not (A D . A)
SUBST returns a copy of EXPR with the appropriate changes. Furthermore,
if NEW is a list, it is copied at each substitution.
If the standard called it "IL:SUBST" then we wouldn't have to do any
work. :-).
∂07-Jul-86 1127 FAHLMAN@C.CS.CMU.EDU Argument lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Jul 86 11:27:00 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 7 Jul 86 14:22:43-EDT
Date: Mon, 7 Jul 1986 14:22 EDT
Message-ID: <FAHLMAN.12220829722.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Alan Snyder <snyder%hplsny@HPLABS.HP.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: Argument lists
In-reply-to: Msg of 3 Jul 1986 08:39-EDT from Alan Snyder <snyder%hplsny at hplabs.HP.COM>
Let's add both FUNCTION-PARAMETERS and FUNCTION-PARAMETER-RANGE.
Isn't the proper "Common Lisp" solution to this issue to say that the compiler
ought to recognize calls to FUNCTION-PARAMETERS that only use the first two
values and, in implementations where FUNCTION-PARAMETER-RANGE would be faster,
convert those calls to calls on SYS:FUNCTION-PARAMETER-RANGE (now an internal
function)?
Let me try to simulate KMP here, since the FUNCTION-PARAMETER-RANGE
function is being proposed for him. Yes, a smart enough compiler could
recognize those cases of FUNCTION-PARAMETERS which could be fast and
non-consing and do the right thing. If this were required behavior,
then people desiring speed could use FUNCTION-PARAMETERS with confidence
that there would be no consing or groveling the code for parameters that
are not really needed. However, it would be unprecedented, and probably
a bad idea, to require that every compiler do this clever thing, and
without such a requirement many implementations would skip this. People
writing applications like the ones KMP has in mind would not be able to
use FUNCTION-PARAMETERS if it is important to them that there be no
consing in any reasonable implementation. On the other hand, there is
no temptatation to do consing for FUNCTION-PARAMETER-RANGE, so it would
be non-consing in any halfway decent implementation, without our having
to require explicitly that it avoids consing.
-- Scott
∂07-Jul-86 1144 gls@Think.COM Argument lists
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 7 Jul 86 11:44:19 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Mon, 7 Jul 86 14:44:17 edt
Date: Mon, 7 Jul 86 14:45 EDT
From: Guy Steele <gls@Think.COM>
Subject: Argument lists
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12220829722.BABYL@C.CS.CMU.EDU>
Message-Id: <860707144509.1.GLS@BOETHIUS.THINK.COM>
Date: Mon, 7 Jul 1986 14:22 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
...
However, it would be unprecedented, and probably
a bad idea, to require that every compiler do this clever thing, and
without such a requirement many implementations would skip this. People
writing applications like the ones KMP has in mind would not be able to
use FUNCTION-PARAMETERS if it is important to them that there be no
consing in any reasonable implementation. On the other hand, there is
no temptatation to do consing for FUNCTION-PARAMETER-RANGE, so it would
be non-consing in any halfway decent implementation, without our having
to require explicitly that it avoids consing.
Also unprecedented in Common Lisp is the notion that a function be
explicitly documented as not consing. Perhaps we want to introduce
such a notion into the documentation, but it has repercussions far
greate than on FUNCTIOn-PARAMETER-RANGE.
--Guy
∂07-Jul-86 1206 FAHLMAN@C.CS.CMU.EDU Argument lists
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Jul 86 12:05:51 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 7 Jul 86 15:05:51-EDT
Date: Mon, 7 Jul 1986 15:05 EDT
Message-ID: <FAHLMAN.12220837575.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@ZARATHUSTRA.THINK.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: Argument lists
In-reply-to: Msg of 7 Jul 1986 14:45-EDT from Guy Steele <gls at Think.COM>
I think that we should not get into the business of requiring that
particular forms not cons or that they be efficient in other ways.
That's opening Pandora's box. In some cases (e.g. multiple values) the
whole idea of the construct is to make it possible to avoid consing, and
we may point that out, but we shouldn't prescribe or forbid certain
implementation techniques. In some strange future implementaiton,
consing might be faster than anything else, even if you count GC time
(or have some way of avoiding gc).
-- Scott
∂07-Jul-86 1212 @MIT-LIVE-OAK.ARPA:JAR@MIT-AI.ARPA compiler-let
Received: from LIVE-OAK.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Jul 86 12:11:59 PDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 3718; Mon 7-Jul-86 15:15:52-EDT
Date: Mon, 7 Jul 86 15:13 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: compiler-let
To: common-lisp@SU-AI.ARPA
Message-ID: <860707151336.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
COMPILER-LET seems pretty confused; CLtL says that it is intended
"for communication among complicated macros," but as far as I can tell
it doesn't reliably serve this end, since its effect is not the same in
interpreted and compiled code. Consider the following example:
(defvar *foo* nil)
(defmacro foo () `',*foo*)
(defun test ()
(compiler-let ((*foo* t))
#'(lambda () (foo))))
Now if TEST is "interpreted," then (funcall (test)) presumably returns
NIL; if it's "compiled," then (funcall (test)) presumably returns T.
Thus the binding of the variable *FOO* is not reliably communicated to
the macro FOO.
Of course, the fact that COMPILER-LET has different meanings in
"interpreted" and "compiled" code is in conflict with th "consistency"
statement on page 2. If COMPILER-LET is to be made meaningful, a
precise distinction between the interpreted language and the compiled
language must be made somewhere, and this is something I haven't seen so
far. Such a distinction would necessarily and absurdly cramp the styles
of "interpreters" and "compilers," e.g. by dictating when macro
expansion must happen (must a compiler expand macros? must an
interpreter avoid doing so until the code is actually executed?).
Is there any kind of thing which can be done using COMPILER-LET which
can't be done using MACROLET? E.g., if you want a macro FOO to expand
to one thing when a (FOO ...) form occurs lexically inside of a (BAR
...) form, but otherwise to something else, one is tempted to write
(defvar *inside-bar-p* nil)
(defmacro bar (&body body)
`(compiler-let ((*inside-bar-p* t))
(progn ,@body)))
(defmacro foo () `',*inside-bar-p*)
(foo) => nil
(bar (foo)) => t
but this fails in exactly the same way the previous example does:
(funcall (bar #'(lambda () (foo)))) => ??
(let ((fun #'(lambda () (foo)))) (bar (funcall fun))) => ??
MACROLET works much better; there are several ways to achieve the
desired effect.
(defmacro foo () ''nil)
(defmacro bar (&body body)
`(macrolet ((foo () ''t))
(progn ,@body)))
(foo) => nil
(bar (foo)) => t
(funcall (bar #'(lambda () (foo)))) => t
(let ((fun #'(lambda () (foo)))) (bar (funcall fun))) => nil
or, alternatively:
(defmacro foo (&environment e)
(if (macroexpand '(inside-bar-p) e) ''t ''nil))
(defmacro inside-bar-p () 'nil) ;macroexpands to t or nil
(defmacro bar (&body body)
`(macrolet ((inside-bar-p () 't))
(progn ,@body)))
etc. That is, the macro environment can be used reliably as a
communications device, without being sensitive to how the code is being
processed.
I'm surprised that people writing code-walkers haven't complained about
COMPILER-LET before (sorry if you have and I've forgotten). I can't
imagine what one is supposed to take COMPILER-LET to mean if one is
trying to understand the meaning of a program, instead of just trying
to run it.
If I had my way, I think I'd have COMPILER-LET excised, and if macros
need to communicate with each other (a dubious proposition in the first
place: can someone provide a realistic example?), the environments
passed by MACROEXPAND to macro expanders can be used as a communcations
channel.
Another alternative is to require that macros always be pre-expanded
even in "interpreted" code, and process COMPILER-LET's at this time;
this would synchronize the MACROEXPAND environment with special variable
bindings, so that source-code-lexical and expand-time-dynamic would mean
the same thing. But this would require nontrivial changes to
implementations.
Jonathan
∂07-Jul-86 1249 shebs%utah-orion@utah-cs.arpa Re: compiler-let
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 7 Jul 86 12:49:18 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA26991; Mon, 7 Jul 86 13:45:41 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA17899; Mon, 7 Jul 86 13:45:37 MDT
Date: Mon, 7 Jul 86 13:45:37 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8607071945.AA17899@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: compiler-let
Summary:
Expires:
References: <860707151336.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <860707151336.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU> JAR@MIT-AI.ARPA (Jonathan A Rees) writes:
>COMPILER-LET seems pretty confused;
Hear, hear!
>Of course, the fact that COMPILER-LET has different meanings in
>"interpreted" and "compiled" code is in conflict with th "consistency"
>statement on page 2. If COMPILER-LET is to be made meaningful, a
>precise distinction between the interpreted language and the compiled
>language must be made somewhere, and this is something I haven't seen so
>far.
Since interpreter/compiler/strange evaluator consistency is one of the
few things that almost everybody agrees is good about Common Lisp,
it should take precedence over anything that would damage this;
COMPILER-LET should be flushed, and EVAL-WHEN, and I wouldn't mind
some constraints on macros in general, although there's not much
prospect for that...
>I'm surprised that people writing code-walkers haven't complained about
>COMPILER-LET before (sorry if you have and I've forgotten).
For PCLS we took advantage of subsetness and totally ignored COMPILER-LET,
since nobody could figure out what it was really for or how a user could
use it in correct code.
stan
∂07-Jul-86 1507 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: compiler-let
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 7 Jul 86 15:07:36 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 36864; Mon 7-Jul-86 18:04:45 EDT
Date: Mon, 7 Jul 86 18:10 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: compiler-let
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8607071945.AA17899@utah-orion.ARPA>
Message-ID: <860707181000.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
To: shebs@utah-orion.UUCP
Date: Mon, 7 Jul 86 13:45:37 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
For PCLS we took advantage of subsetness and totally ignored COMPILER-LET,
since nobody could figure out what it was really for or how a user could
use it in correct code.
That's a very good way to make design decisions.
It's certainly true that CLtL does not explain compiler-let well enough.
A single example would probably help a great deal.
For purposes of future manual revisions: what other features did you
totally ignore for the same reasons?
∂07-Jul-86 1614 shebs%utah-orion@utah-cs.arpa Re: compiler-let
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 7 Jul 86 16:14:05 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA05923; Mon, 7 Jul 86 17:10:29 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA18578; Mon, 7 Jul 86 17:10:25 MDT
Date: Mon, 7 Jul 86 17:10:25 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8607072310.AA18578@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: compiler-let
Summary:
Expires:
References: <860707181000.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <860707181000.8.DLW@CHICOPEE.SCRC.Symbolics.COM> DLW@QUABBIN.SCRC.Symbolics.COM (Daniel L. Weinreb) writes:
>To: shebs@utah-orion.UUCP
>
> Date: Mon, 7 Jul 86 13:45:37 MDT
> From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
>
> For PCLS we took advantage of subsetness and totally ignored COMPILER-LET,
> since nobody could figure out what it was really for or how a user could
> use it in correct code.
>
>That's a very good way to make design decisions.
>
>It's certainly true that CLtL does not explain compiler-let well enough.
>A single example would probably help a great deal.
>
>For purposes of future manual revisions: what other features did you
>totally ignore for the same reasons?
Methinks there is a tongue pressed into cheek somewhere, but I'll answer
bravely anyway: COMPILER-LET takes honors as the most bogus item in
Common Lisp, with the possible exception of certain format directives
(GLS's example of the FORMAT-ERROR function is an unusually subtle joke -
"looks pretty flashy when done properly"!). PCLS includes FIFTH through
TENTH, but that was because they were so easy that people spent time on
those to avoid working on useful functions. We used to be prejudiced
against MACROLET, but have since been partially convinced of its worth,
and it's likely to appear in the next version of PCLS. There was also
a move afoot to flush CONS because it consed immensely, but everybody's
resigned to keeping it in PCLS...
stan
∂07-Jul-86 1733 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM compiler-let
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 7 Jul 86 17:33:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 36946; Mon 7-Jul-86 20:30:53 EDT
Date: Mon, 7 Jul 86 20:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: compiler-let
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860707151336.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
Message-ID: <860707203141.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 7 Jul 86 15:13 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
COMPILER-LET seems pretty confused; CLtL says that it is intended
"for communication among complicated macros," but as far as I can tell
it doesn't reliably serve this end, since its effect is not the same in
interpreted and compiled code. Consider the following example:
(defvar *foo* nil)
(defmacro foo () `',*foo*)
(defun test ()
(compiler-let ((*foo* t))
#'(lambda () (foo))))
Now if TEST is "interpreted," then (funcall (test)) presumably returns
NIL; if it's "compiled," then (funcall (test)) presumably returns T.
It always returns T in the implementation on my machine.
But I see your point. If the macro foo was not expanded until after the
closure was made, and if the interpreter failed to include the COMPILER-LET
information in the closure, it would return NIL.
This is item #300 (or thereabouts) among the minor design decisions that
were not reevaluated when full lexical scoping was added to the language
late in the process of designing Common Lisp. Perhaps there should be a
committee of interested persons to search for these systematically. To
get you started, #259 is: what does this form do?
(dotimes (i n) (push #'(lambda () i) l))
I don't know why you say COMPILER-LET is difficult to handle in code-walkers.
I think it might be the second-easiest special form, after QUOTE. You just
bind the special variables and proceed.
Is there any kind of thing which can be done using COMPILER-LET which
can't be done using MACROLET?
MACROLETs aren't visible in the scope of the body of a macro expansion
function. That's the whole reason why COMPILER-LET uses dynamic
scoping. I thought about this a bit and looked at some real examples,
too large and unilluminating to include here. I think the answer is
that since COMPILER-LET can only affect the expansion of macros, it can
always be replaced with a MACROLET that redefines the macro to a new
version of its body with the COMPILER-LET variable's value included in
the macro as a constant. This gets cumbersome when the macro definition
is large (this can be addressed by calling a subroutine) or when there
are nested COMPILER-LETs for different variables or variables that are
not constant but depend on the particular macro call (I haven't figured
out how to cope with that, other than by using the trick of explicitly
calling MACROEXPAND that you had in your mail, which is essentially using
the MACROLET environment to simulate deep-bound special variables).
Another reason for COMPILER-LET, no doubt bogus, can be found in the
Lisp Machine manual ("Chine Nual"). It can be used to bind switches
that affect the operation of the compiler. Presumably this could be
done with declarations or special forms, at some small increase in
compiler complexity. Except for this application, COMPILER-LET doesn't
appear to have anything to do specifically with compilers, and is
evidently misnamed.
∂07-Jul-86 1816 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM DECLARE SPECIAL Considered Confusing
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 7 Jul 86 18:15:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 36962; Mon 7-Jul-86 20:58:58 EDT
Date: Mon, 7 Jul 86 20:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DECLARE SPECIAL Considered Confusing
To: Pavel.pa@Xerox.COM
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860705-165424-2715@Xerox>
Message-ID: <860707205952.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I do not wish to defend the current choice of declaration-scoping rules
in Common Lisp as the best or only choice, but I do wish to clarify what
the rules are in the language as it is currently defined. It wouldn't
bother me if a future revision of the language adopted simpler rules,
provided they were truly (not just superficially) simpler.
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
I have a question concerning some ambiguity in the description of the
scope of a special declaration inside a LET. Consider this code:
(setq foo 6)
(let ((foo 7))
(let ((foo (1+ foo)))
(declare (special foo))
foo))
Both Symbolics and CLISP return 8 for this, but VAXLISP returns 7.
VAXLISP is incorrect here. The SPECIAL declaration is pervasive for
references (but non-pervasive for bindings). Because SPECIAL is
pervasive for references it affects the reference to foo inside 1+.
Clearly, the question is whether or not the special declaration covers
the init-form of the enclosing LET or just the bindings themselves.
According to the ``nonsense'' example in CLtL, page 155, the reference
to ``foo'' in the call to 1+ should be special. The GLS clarification
for page 159, however, seems to support a different philosophy:
``(*) 159 Clarify that in the following example
(defun foo (x)
(declare (inline bar))
(bar x) ; first
(flet ((bar (z) (bar (+ z 1)))) ; second
(bar x)) ; third
(bar x) ; fourth
the first, second and fourth calls to BAR are affected by the INLINE
declaration, but not the third one.''
This seems to support the view that the init-form of a binding is in a
scope outside of that of the binding itself and the body of the LET (or
FLET or ...). I prefer this view.
The scoping of variables (and FLET functions) is different from the
scoping of pervasive declarations. There is no analogy between this
example and your previous one, because the INLINE declaration is not
attached to a binding, but the SPECIAL declaration is attached to a
binding. All that's shown by this clarification is that INLINE, just
like SPECIAL, is shadowed by an occurrence of another binding of the
same name inside its scope.
Incidentally, the bottom of p.154 says that SPECIAL is the only
declaration that falls into both classes, but I think INLINE is really
in the same category. It concerns a particular binding, but can also be
used in the absence of a binding and is pervasive for references, just
like SPECIAL.
I would like to propose the following rule for the scope of declarations
in binding forms:
``A declaration in a binding form (such as LET) affects the body of the
form and the bindings themselves. It does not affect the init-forms for
the bindings; they are in the same scope as the binding form as a
whole.''
This rule has the advantage (over the rule given for the nonsense
example) that the scope of the declarations is the same as the scope of
the bindings. Thus, for the nonsense example:
(defun nonsense (k x z)
(foo z x) ;First call to foo
(let ((j (foo k x)) ;Second call to foo
(x (* k k)))
(declare (inline foo)
(special x z))
(foo x j z))) ;Third call to foo
the inline declaration affects only the third call to foo (not the
second) and only the references to x and z in the third call to foo are
special (not the reference to x in the second call).
There would be only two exceptions to this rule:
-- In a LABELS binding, references in the definitions of the functions
to the very functions being bound would be affected by any declarations
affecting the bindings themselves. This makes sense because of the
recursive quality of the binding.
-- The PROCLAIM function establishes pervasive declarations, covering
all bindings of and references to the symbols named. Such declarations
can, of course, be countermanded by local declarations or later
proclamations.
What about declarations inside the body of DEFUN? With your rules I cannot see
how a declaration could ever affect the default value forms for &optional, &key,
and &aux variables. And what about declarations inside the body of a LET*? The
scoping of ones attached to variables is fairly obvious, but what about ones
not attached to variables?
We went all through this during the design of Common Lisp (I think the discussion
is available online) and the current rules resulted. Given that we must have
DECLARE at all (a point which you should not necessarily be willing to concede),
the current rules seem to work more consistently than the alternatives that were
considered.
∂07-Jul-86 1945 NGALL@G.BBN.COM Re: DECLARE SPECIAL Considered Confusing
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 7 Jul 86 19:45:22 PDT
Date: 7 Jul 1986 22:44-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: DECLARE SPECIAL Considered Confusing
From: NGALL@G.BBN.COM
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: Pavel.pa@XEROX.COM, Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM] 7-Jul-86 22:44:13.NGALL>
In-Reply-To: <860707205952.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 7 Jul 86 20:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
To: Pavel.pa@Xerox.COM
Subject: DECLARE SPECIAL Considered Confusing
In-Reply-To: <860705-165424-2715@Xerox>
Message-ID: <860707205952.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
...
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
I have a question concerning some ambiguity in the description of the
scope of a special declaration inside a LET. Consider this code:
(setq foo 6)
(let ((foo 7))
(let ((foo (1+ foo)))
(declare (special foo))
foo))
Both Symbolics and CLISP return 8 for this, but VAXLISP returns 7.
VAXLISP is incorrect here. The SPECIAL declaration is pervasive for
references (but non-pervasive for bindings). Because SPECIAL is
pervasive for references it affects the reference to foo inside 1+.
I don't wish to add to the confusion here, but my reading of pg 155
agrees with VaxLisp: the above example should return 7. The outermost
LET binds a lexical var. named foo that is never referenced. The
special declaration in the inner LET affects the variable being bound
by the LET (foo) and it affects the reference to foo in the explicit
body (i.e. the last reference to foo) and the reference to foo in the
init-form in the inner LET is also special. The global value of foo
is 6, and 6 + 1 = 7.
-- Nick
∂07-Jul-86 2016 Moon@QUABBIN.SCRC.Symbolics.COM DECLARE SPECIAL Considered Confusing
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 7 Jul 86 20:15:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17091; Mon 7-Jul-86 23:13:40 EDT
Date: Mon, 7 Jul 86 23:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DECLARE SPECIAL Considered Confusing
To: Pavel.pa@Xerox.COM
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860705-165424-2715@Xerox>
Supersedes: <860707205952.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860707231340.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I do not wish to defend the current choice of declaration-scoping rules
in Common Lisp as the best or only choice, but I do wish to clarify what
the rules are in the language as it is currently defined. It wouldn't
bother me if a future revision of the language adopted simpler rules,
provided they were truly (not just superficially) simpler.
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
I have a question concerning some ambiguity in the description of the
scope of a special declaration inside a LET. Consider this code:
(setq foo 6)
(let ((foo 7))
(let ((foo (1+ foo)))
(declare (special foo))
foo))
Both Symbolics and CLISP return 8 for this, but VAXLISP returns 7.
VAXLISP is correct here. The SPECIAL declaration is pervasive for
references (but non-pervasive for bindings). Because SPECIAL is
pervasive for references it affects the reference to foo inside 1+.
I apologize for the incorrect earlier version of this message that
said that VAXLISP was incorrect here. I didn't mean to add to the
confusion; it must have been a Freudian slip.
Incidentally, the incorrect result returned here by the Symbolics
implementation is a (poorly) documented incompatibility with Common
Lisp that will be fixed at some time in the future.
Clearly, the question is whether or not the special declaration covers
the init-form of the enclosing LET or just the bindings themselves.
According to the ``nonsense'' example in CLtL, page 155, the reference
to ``foo'' in the call to 1+ should be special. The GLS clarification
for page 159, however, seems to support a different philosophy:
``(*) 159 Clarify that in the following example
(defun foo (x)
(declare (inline bar))
(bar x) ; first
(flet ((bar (z) (bar (+ z 1)))) ; second
(bar x)) ; third
(bar x) ; fourth
the first, second and fourth calls to BAR are affected by the INLINE
declaration, but not the third one.''
This seems to support the view that the init-form of a binding is in a
scope outside of that of the binding itself and the body of the LET (or
FLET or ...). I prefer this view.
The scoping of variables (and FLET functions) is different from the
scoping of pervasive declarations. There is no analogy between this
example and your previous one, because the INLINE declaration is not
attached to a binding, but the SPECIAL declaration is attached to a
binding. All that's shown by this clarification is that INLINE, just
like SPECIAL, is shadowed by an occurrence of another binding of the
same name inside its scope.
Incidentally, the bottom of p.154 says that SPECIAL is the only
declaration that falls into both classes, but I think INLINE is really
in the same category. It concerns a particular binding, but can also be
used in the absence of a binding and is pervasive for references, just
like SPECIAL.
I would like to propose the following rule for the scope of declarations
in binding forms:
``A declaration in a binding form (such as LET) affects the body of the
form and the bindings themselves. It does not affect the init-forms for
the bindings; they are in the same scope as the binding form as a
whole.''
This rule has the advantage (over the rule given for the nonsense
example) that the scope of the declarations is the same as the scope of
the bindings. Thus, for the nonsense example:
(defun nonsense (k x z)
(foo z x) ;First call to foo
(let ((j (foo k x)) ;Second call to foo
(x (* k k)))
(declare (inline foo)
(special x z))
(foo x j z))) ;Third call to foo
the inline declaration affects only the third call to foo (not the
second) and only the references to x and z in the third call to foo are
special (not the reference to x in the second call).
There would be only two exceptions to this rule:
-- In a LABELS binding, references in the definitions of the functions
to the very functions being bound would be affected by any declarations
affecting the bindings themselves. This makes sense because of the
recursive quality of the binding.
-- The PROCLAIM function establishes pervasive declarations, covering
all bindings of and references to the symbols named. Such declarations
can, of course, be countermanded by local declarations or later
proclamations.
What about declarations inside the body of DEFUN? With your rules I cannot see
how a declaration could ever affect the default value forms for &optional, &key,
and &aux variables. And what about declarations inside the body of a LET*? The
scoping of ones attached to variables is fairly obvious, but what about ones
not attached to variables?
We went all through this during the design of Common Lisp (I think the discussion
is available online) and the current rules resulted. Given that we must have
DECLARE at all (a point which you should not necessarily be willing to concede),
the current rules seem to work more consistently than the alternatives that were
considered.
∂08-Jul-86 1003 hpfclp!diamant@hplabs.HP.COM compiler-let
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 8 Jul 86 09:59:46 PDT
Received: by hplabs.HP.COM ; Tue, 8 Jul 86 09:57:30 pdt
Date: Tue, 8 Jul 86 09:57:30 pdt
From: hpfclp!diamant@hplabs.HP.COM
To: common-lisp@su-ai.ARPA
Subject: compiler-let
Subject: compiler-let
From: David A. Moon <hplabs!Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Mon, 7 Jul 86 15:13 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
COMPILER-LET seems pretty confused; CLtL says that it is intended
"for communication among complicated macros," but as far as I can tell
it doesn't reliably serve this end, since its effect is not the same in
interpreted and compiled code. Consider the following example:
(defvar *foo* nil)
(defmacro foo () `',*foo*)
(defun test ()
(compiler-let ((*foo* t))
#'(lambda () (foo))))
Now if TEST is "interpreted," then (funcall (test)) presumably returns
NIL; if it's "compiled," then (funcall (test)) presumably returns T.
It always returns T in the implementation on my machine.
It also always returns T on my machine (HP Common Lisp).
But I see your point. If the macro foo was not expanded until after the
closure was made, and if the interpreter failed to include the COMPILER-LET
information in the closure, it would return NIL.
I certainly agree with Jonathan that as stated in CLtL, COMPILER-LET is
bogus. When implementing this special form, we determined that (if we
were to believe the intent stated for COMPILER-LET) the bindings must be in
effect in the same context that the macroexpansion will occur. The statement
made in CLtL for the compiler is correct as all Common Lisp implementations
are required to expand macros at compile time (see page 143). However,
the statement that COMPILER-LET behaves like LET in the interpreter implictly
assumes that macros are expanded at eval time in the interpreter. Since this
is not true in our implementation, we had to decide what was needed to make
COMPILER-LET perform as needed. This meant that for our implementation,
COMPILER-LET does the same thing whether interpreted or compiled (it sets
up bindings in the preprocessor environment -- which is when macroexpansion
occurs in our system).
I am not sure whether COMPILER-LET should remain in the language or not, but
I think that the correction to the description which I mentioned does make
it meaningful (although terribly misnamed).
John
∂08-Jul-86 1003 gls@Think.COM [gls@Think.COM: Re: compiler-let]
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 8 Jul 86 10:03:06 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Tue, 8 Jul 86 13:03:15 edt
Date: Tue, 8 Jul 86 13:04 EDT
From: Guy Steele <gls@Think.COM>
Subject: [gls@Think.COM: Re: compiler-let]
To: common-lisp@SU-AI.ARPA
Message-Id: <860708130406.5.GLS@BOETHIUS.THINK.COM>
Date: Mon, 7 Jul 86 17:10:25 MDT
From: shebs%utah-orion@utah-cs.ARPA (Stanley Shebs)
...
Methinks there is a tongue pressed into cheek somewhere, but I'll answer
bravely anyway: COMPILER-LET takes honors as the most bogus item in
Common Lisp, with the possible exception of certain format directives
(GLS's example of the FORMAT-ERROR function is an unusually subtle joke -
"looks pretty flashy when done properly"!).
In this connection, I would like to nominate the following for Most Unreadable
Format Control String in Production Code:
"~:[{~;[~]~:{~S~:[!~S~;~*~]~:↑ ~}~:[ ~]~{~S!~↑ ~}~:[ ~]~[~*~;!~S~;. ~S~;!~*~]~:[}~;]~]"
I am not kidding; I wrote this as part of the Connection Machine Lisp simulator,
and it really does do exactly what I want. It is part of the printing function
for a data structure called a xapping, whose syntax involves brackets or braces
under various circumstances. Here is the entire printing function:
(defun print-xapping (xapping stream depth)
(declare (ignore depth))
(format stream
"~:[{~;[~]~:{~S~:[!~S~;~*~]~:↑ ~}~:[ ~]~{~S!~↑ ~}~:[ ~]~[~*~;!~S~;. ~S~;!~*~]~:[}~;]~]"
;\←←←←←←←/\←←←←←←←←←←←←←←←←←←←←←/\←←←←/\←←←←←←←←/\←←←←/\←←←←←←←←←←←←←←←←←←←←/\←←←←←←←/
(xectorp xapping)
(do ((vp (xectorp xapping))
(sp (finite-part-is-xetp xapping))
(d (xapping-domain xapping) (cdr d))
(r (xapping-range xapping) (cdr r))
(z '() (cons (list (if vp (car r) (car d))
(or vp sp)
(car r))
z)))
((null d) (reverse z)))
(not (and (xapping-domain xapping)
(or (xapping-exceptions xapping)
(xapping-infinite xapping))))
(xapping-exceptions xapping)
(not (or (and (xapping-exceptions xapping)
(xapping-infinite xapping))
(and (eq (xapping-infinite xapping) :lazy)
(null (xapping-domain xapping))
(null (xapping-exceptions xapping)))))
(ecase (xapping-infinite xapping)
(:constant 1)
(:lazy 2)
(:universal 3)
((nil) 0))
(xapping-default xapping)
(xectorp xapping)))
∂08-Jul-86 1257 snyder%hplsny@hplabs.HP.COM Re: Compiler recognizing uses of only two values
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 8 Jul 86 12:56:22 PDT
Received: from hplsny by hplabs.HP.COM ; Tue, 8 Jul 86 12:54:00 pdt
Received: by hplsny ; Tue, 8 Jul 86 12:54:00 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8607081954.AA13185@hplsny>
Date: Tuesday, July 8, 1986 12:53:47
Subject: Re: Compiler recognizing uses of only two values
To: KMP@SCRC-STONY-BROOK.ARPA
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 3-Jul-86 11:57:00
X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46
Date: Thu, 3 Jul 86 11:57 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Compiler recognizing uses of only two values
To: snyder%hplsny@hplabs.HP.COM
I had thought about that and decided not to mention it because I fear
someone will take it seriously. It's a good idea, of course, but unless
you practically -- perhaps literally -- require compilers to do hairy
optimizations like this, most people won't bother and I'll be stuck
with having to effectively treat the feature as unavailable on some
systems. Sigh. The problem with portability is that the whole idea is to
allow your program to move from the "reasonable" system you developed
it in to a bunch of "hostile" systems that you didn't develop your code
in -- often for good reason. Perhaps I'm being too pessimistic.
Of course, Common Lisp already has the problem that users and implementors
don't always agree on what "should" be efficient. On the other hand, just
providing the "efficient" function in the language definition doesn't
guarantee that an implementor will implement it efficiently. If he doesn't
share (or is not aware of) your view of its importance, he may implement it by
calling the inefficient function and throwing away the excess values.
Alan
-------
∂08-Jul-86 1355 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: DECLARE SPECIAL Considered Confusing
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 8 Jul 86 13:54:24 PDT
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a002506; 7 Jul 86 19:30 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Mon, 7 Jul 86 19:27:20 -0100
Message-Id: <1672.8607071827@aiva.ed.ac.uk>
To: Common-Lisp@su-ai.arpa, DCP@scrc-quabbin.arpa, Pavel.pa@xerox.com
Subject: Re: DECLARE SPECIAL Considered Confusing
Date: Mon, 7 Jul 86 10:03 EDT
From: "David C. Plummer" <DCP@arpa.scrc-quabbin>
Subject: DECLARE SPECIAL Considered Confusing
Date: 5 Jul 86 16:54 PDT
From: Pavel.pa@Xerox.COM
What do people think? It would appear that some implementations already
work this way.
I agree. Consider LET to be a macro that turns into LAMBDA:
(let ((foo (1+ foo)))
(declare (special foo))
foo)
=> ((lambda (foo)
(declare (special foo))
foo)
(1+ foo))
[I think this is what MacLisp actually did (does?).] The scoping here
is clear: the foo in (1+ foo) is outside the scope of the declaration.
If the SPECIAL declaration is to apply to the init forms, LET can be
a macro that turns into two lambdas:
(let ((foo (1+ foo))) (declare (special foo)) foo)
=> ((lambda ()
(declare (special foo))
((lambda (foo) foo) (declare (special foo)) (1+ foo))))
Some implementations do work this way.
∂08-Jul-86 1832 FAHLMAN@C.CS.CMU.EDU Editorial Comment
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Jul 86 18:32:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 8 Jul 86 21:32:28-EDT
Date: Tue, 8 Jul 1986 21:32 EDT
Message-ID: <FAHLMAN.12221170104.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@ZARATHUSTRA.THINK.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: Editorial Comment
In-reply-to: Msg of 8 Jul 1986 13:04-EDT from Guy Steele <gls at Think.COM>
:-(
"~:[{~;[~]~:{~S~:[!~S~;~*~]~:↑ ~}~:[ ~]~{~S!~↑ ~}~:[ ~]~[~*~;!~S~;. ~S~;!~*~]~:[}~;]~]"
)-: !!!
∂09-Jul-86 0653 DLW@QUABBIN.SCRC.Symbolics.COM compiler-let
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 9 Jul 86 06:53:31 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17243; Tue 8-Jul-86 14:39:38 EDT
Date: Tue, 8 Jul 86 14:45 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: compiler-let
To: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 8 Jul 86 12:57 EDT from hpfclp!diamant@hplabs.HP.COM
Message-ID: <860708144532.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
I agree with much of what's been said. I'd just like to add that the
really bogus thing is that compiler-let is defined in terms of "the
interpreter does this, the compiler does that", in a language where the
whole point is that they do the same thing. The definition should be in
terms of the actual semantics of the language, without reference to the
interpreter or compiler. Of course, that's hard, but it would also
point up some of the same problems that we've been discussing. I also
agree that the name is terrible. If everything important that it does
can be done just as well with macrolet, then perhaps simply removing
compiler-let is the right thing to do.
Historical note: the first edition Lisp Machine Manual [Weinreb and Moon
1978] lists this form, and explains it primarily as a way to control
compiler-directive flags (which is really bogus for CL), and secondarily
to bind flags that affect macro expansion. This survived into the later
editions of the manual. So I certainly take some blame for this mess.
The Symbolics documentation has been improved a lot by someone, and
while it retains the old compiler-flag stuff, it also includes a good
example of what compiler-let is really for. Interestingly, it then
shows how to do the same thing with macrolet!
∂09-Jul-86 0810 loral!jvz@sdcsvax.ucsd.edu
Received: from SDCSVAX.UCSD.EDU by SU-AI.ARPA with TCP; 9 Jul 86 08:09:46 PDT
Received: by sdcsvax.ucsd.edu (5.31/4.42)
id AA03774; Tue, 8 Jul 86 18:09:33 PDT hops=0
Received: by sdcc6.ARPA (5.51/4.41)
id AA25847; Tue, 8 Jul 86 18:08:41 PDT
Received: from sally.LORAL (sally.ARPA) by loral.UUCP (4.12/4.7)
id AA08598; Tue, 8 Jul 86 11:18:03 pdt
Received: by sally.LORAL (5.45/4.7)
id AA11840; Tue, 8 Jul 86 11:21:53 PDT
Date: Tue, 8 Jul 86 11:21:53 PDT
From: loral!jvz@sdcsvax.ucsd.edu (John Van Zandt)
Message-Id: <8607081821.AA11840@sally.LORAL>
To: Common-Lisp@su-ai.arpa
Please add me to your mailing list.
Thanks,
John Van Zandt jvz@UCSD
Engineering Mgr
DataFlo(tm) Computer Products
Loral Instrumentation
∂09-Jul-86 1014 gls@Think.COM Editorial Comment
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 9 Jul 86 10:14:13 PDT
Received: from faustinas by Godot.Think.COM via CHAOS; Wed, 9 Jul 86 13:14:15 edt
Date: Wed, 9 Jul 86 13:15 EDT
From: Guy Steele <gls@Think.COM>
Subject: Editorial Comment
To: Fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <FAHLMAN.12221170104.BABYL@C.CS.CMU.EDU>
Message-Id: <860709131505.2.GLS@FAUSTINUS.THINK.COM>
Date: Tue, 8 Jul 1986 21:32 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
:-(
"~:[{~;[~]~:{~S~:[!~S~;~*~]~:↑ ~}~:[ ~]~{~S!~↑ ~}~:[ ~]~[~*~;!~S~;. ~S~;!~*~]~:[}~;]~]"
)-: !!!
Well, it seemed clear when I wrote it...
∂09-Jul-86 1024 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: DECLARE SPECIAL
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 9 Jul 86 10:24:02 PDT
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a000970; 9 Jul 86 18:13 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Wed, 9 Jul 86 18:11:41 -0100
Message-Id: <20095.8607091711@aiva.ed.ac.uk>
To: common-lisp@su-ai.arpa
Subject: Re: DECLARE SPECIAL
Sorry. I seem to have blown it again. The macro expansion for special
declarations inside a LET should be:
(let ((foo (1+ foo))) (declare (special foo)) foo)
==> ((lambda ()
(declare (special foo)) ;decl for init form
((lambda (foo)
(declare (special foo))
foo)
(1+ foo))))
Anyway, if you try this kind of LET in some implementations, you'll find
that they get it right (the special declaration applies to the foo in
the init form) in the compiler but not in the interpreter.
-- Jeff
∂09-Jul-86 1032 berman@vaxa.isi.edu Re: Editorial Comment
Received: from VAXA.ISI.EDU by SU-AI.ARPA with TCP; 9 Jul 86 10:32:39 PDT
Received: by vaxa.isi.edu (4.12/4.7)
id AA25842; Wed, 9 Jul 86 10:32:06 pdt
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8607091732.AA25842@vaxa.isi.edu>
Date: 9 Jul 1986 1032-PDT (Wednesday)
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Re: Editorial Comment
In-Reply-To: Your message of Tue, 8 Jul 1986 21:32 EDT.
<FAHLMAN.12221170104.BABYL@C.CS.CMU.EDU>
Merci.
∂09-Jul-86 1218 wft@gandalf.cs.cmu.edu Concurrent Lisp
Received: from GANDALF.CS.CMU.EDU by SU-AI.ARPA with TCP; 9 Jul 86 12:18:20 PDT
Date: Wed, 9 Jul 86 15:16:25 EDT
From: Walter.Tichy@GANDALF.CS.CMU.EDU
To: common-lisp@su-ai
Subject: Concurrent Lisp
I'm looking for information on the following:
1. What concurrent processing and synchronization primitives have evolved
in the Lisp community?
(supporting the model of "communicating sequential processes",
not so much the "massively" parallel stuff.)
2. Is there any work addressing the problem of simultaneous
access and updates to semantic nets?
3. What about distributed semantic nets or distributed shared memory?
-Walter Tichy
tichy@gandalf.cs.cmu.edu
∂09-Jul-86 1341 LOOSEMORE@UTAH-20.ARPA more editorial comment on format
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 9 Jul 86 13:40:55 PDT
Date: Wed 9 Jul 86 14:39:09-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: more editorial comment on format
To: common-lisp@SU-AI.ARPA
Message-ID: <12221378859.20.LOOSEMORE@UTAH-20.ARPA>
Some years ago, while taking a software engineering class, I heard a
lecture on "The Magical Number Seven". Essentially, the idea is that
people get confused if confronted with more than seven options or
choices at one time. Wouldn't it be nice if we only had to remember
7 obscure format commands, instead of 30 (plus all of their innumerable
modifiers and variations)? Personally, I think that if you need to use
more than ~a, ~s, ~%, ~t, and ~~, you should be writing Lisp code to
do the formatting instead of using this crufty embedded language that
bears no resemblance or relationship to the rest of Common Lisp.
It's also unfortunate that there aren't *functions* provided to do some
of the nastier numeric formatting, like ~e and friends. Trying to
imitate the way FORTRAN does it is not necessarily a very good idea.
Anybody who has ever taught FORTRAN knows that FORMAT is by far the
most difficult part of the language to understand. Even experienced
FORTRAN programmers who think they grok FORMAT are continually surprised
by its bizzarities. I suppose that if CL was trying to achieve cultural
compatibility with FORTRAN, it's succeeded....
-Sandra
-------
∂09-Jul-86 1555 jvz@sdcsvax.ucsd.edu mailing list
Received: from SDCSVAX.UCSD.EDU by SU-AI.ARPA with TCP; 9 Jul 86 15:54:19 PDT
Received: by sdcsvax.ucsd.edu (5.31/4.42)
id AA11256; Wed, 9 Jul 86 15:56:39 PDT hops=0
Date: Wed, 9 Jul 86 15:56:39 PDT
From: jvz@sdcsvax.ucsd.edu (John Van Zandt)
Message-Id: <8607092256.AA11256@sdcsvax.ucsd.edu>
To: Common-Lisp@su-ai.arpa
Subject: mailing list
Please add me to your mailing list.
Thanks,
John Van Zandt jvz@UCSD
Engineering Manager
DataFlo(tm) Computer Products
Loral Instrumentation
∂10-Jul-86 0124 @AI.AI.MIT.EDU:STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU more editorial comment on format
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86 01:24:43 PDT
Received: from OZ.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 10 JUL 86 01:06:34 EDT
Date: Thu, 10 Jul 1986 01:02 EDT
Message-ID: <STEVER.12221470455.BABYL@MIT-OZ>
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: common-lisp@SU-AI.ARPA
Subject: more editorial comment on format
In-reply-to: Msg of 9 Jul 1986 16:39-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
Date: Wednesday, 9 July 1986 16:39-EDT
From: SANDRA <LOOSEMORE at UTAH-20.ARPA>
To: common-lisp at SU-AI.ARPA
Re: more editorial comment on format
Personally, I think that if you need to use
more than ~a, ~s, ~%, ~t, and ~~, you should be writing Lisp code to
do the formatting instead of using this crufty embedded language that
bears no resemblance or relationship to the rest of Common Lisp.
I heartily agree! Being a relative novice at using FORMAT (except in
the most straightforward way), I've spent far too much time trying to
get format control strings to do what I want. This seems like a case
of the solution being harder than the problem...
It's also unfortunate that there aren't *functions* provided to do some
of the nastier numeric formatting, like ~e and friends.
Well, you can always:
(defun exp-floating-point (w d e k overflow-char padchar expchar)
(format nil "~v,v,v,v,v,v,vE" w d e k overflow-char padchar
expchar))
... :-)
Stever
∂10-Jul-86 0331 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA GC, exit-to-system
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 10 Jul 86 03:31:12 PDT
Received: from utokyo-relay by csnet-relay.csnet id ai05150; 10 Jul 86 6:32 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA14719; Thu, 10 Jul 86 17:10:52+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA08957; Thu, 10 Jul 86 16:54:22+0900
Date: Thu, 10 Jul 86 16:54:22+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607100754.AA08957@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@CSNET-RELAY.ARPA
Subject: GC, exit-to-system
In the discussion of our committee,
we wondered why the names of the functions for
gc, and exit to system
are NOT defined in CL.
I am only thinking of the interface naming, not the contents, like editor
interface is defined in CL but the editor subsystem is not defined yet.
I think the unified name for them can be defined in CL.
like,
GC &optional parameters [function]
and
BYE [function]
There are lots of names for the function to exit to system.
like, (bye) , (exit), (quit), ...
As an user and as a teacher, I feel happy if the name is only one for
exit-to-system function.
The needs to define a unique name is for user convenience.
As to GC, it is not defined in CL too.
Of cause, there are several ways of GC techniques, and
there are several systems which do not have GC.
We discussed about the needs to define a unique name for it.
We found there are not so much needs, but for writing bench marking
software library.
If we might wanted to stick defining a name for GC, we might found
several situation which need a unique name for GC.
Masayuki Ida
-----
PS: attached is the mail from Scott Fahlman as a reply to my mail.
------------------ Comment for GC by Fahlman ---------------------------
Date: Sun, 8 Jun 1986 02:17 EDT
From: "Scott E. Fahlman" <Fahlman%C.CS.CMU.EDU@u-tokyo.junet>
To: ida%utokyo-relay.csnet@csnet-relay.csnet
Subject: User initiated GC ?
In-Reply-To: Msg of Fri 6 Jun 86 19:01:00+0900 from Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at CSNET-RELAY.ARPA>
Received: from CSNet-Relay by utokyo-relay; 8 Jun 86 19:26:13-JST (Sun)
Status: RO
There is no explicit GC control in Common Lisp because we believed that
garbage collection would vary tremendously from one implementation to
another, and that new ideas for GC might come along in the future.
There are already systems that do mark-and-sweep GC, incremental copying
GC, stop-and-copy GC, reference-count GC with an occasional complete GC,
ephemeral GC (see Moon's paper in the last Lisp conference), and a
proposal by Jon White for a system that would have a huge memory and
would do a GC very rarely. Some systems do a GC because they are really
running out of space; others do a GC just to compact live items and
improve paging performance.
In such a diverse world, it is hard to imagine any use for explicit
GC-control functions that would not be system-dependent. One can
imagine a GC function that says "if the system ever stops to
garbage-collect, do it now", but when would you use this in portable
code? It might take a millisecond on one machine and six hours on
another. It might or might not guarantee that you're safe from further
GC's for a certain period.
So we decided to leave such controls to the discretion of the
implementor on any given system.
-- Scott
------------------- end ----------------------
∂10-Jul-86 0854 MICHAEL@CS.COLUMBIA.EDU A minimal Common Lisp interpreter.
Received: from CS.COLUMBIA.EDU by SU-AI.ARPA with TCP; 10 Jul 86 08:53:45 PDT
Date: Thu 10 Jul 86 11:50:26-EDT
From: Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>
Subject: A minimal Common Lisp interpreter.
To: common-lisp@SU-AI.ARPA
Message-ID: <12221588445.45.MICHAEL@CS.COLUMBIA.EDU>
Does anyone have some measure of how big it would be?
Michael
-------
∂10-Jul-86 1016 unido!uklirb!przy@seismo.CSS.GOV Mailing-list
Received: from seismo.CSS.GOV by SU-AI.ARPA with TCP; 10 Jul 86 09:44:27 PDT
Return-Path: <unido!uklirb!przy>
Received: from unido.UUCP by seismo.CSS.GOV with UUCP; Thu, 10 Jul 86 12:30:59 EDT
Received: by unido.uucp with uucp; Thu, 10 Jul 86 18:00:58 -0200
Received: by uklirb.UUCP (4.12/4.7)
id AA04828; Thu, 10 Jul 86 17:38:53 -0100
Date: Thu, 10 Jul 86 17:38:53 -0100
From: unido!uklirb!przy@seismo.CSS.GOV (Gebhard Przyrembel)
Message-Id: <8607101638.AA04828@uklirb.UUCP>
To: common-lisp@su-ai.arpa
Subject: Mailing-list
Please, remove me from your mailing-list, because the costs are to expansive.
Is there a posibility to send the Commonlisp-Mail to net.lang.lisp in the
notes-system???
Thanks in advance,
Gebhard
/---------------------------------------------------------\
| e-mail: przy@uklirb.UUCP or |
| ..!mcvax!unido!uklirb!przy |
| Real-Name: Gebhard Przyrembel |
| University Kaiserslautern |
| Departement of Computer Sciene |
| D-6750 Kaiserslautern |
| West-Germany |
\---------------------------------------------------------/
∂10-Jul-86 1051 FAHLMAN@C.CS.CMU.EDU A minimal Common Lisp interpreter.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Jul 86 10:50:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 10 Jul 86 13:50:23-EDT
Date: Thu, 10 Jul 1986 13:50 EDT
Message-ID: <FAHLMAN.12221610242.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: A minimal Common Lisp interpreter.
In-reply-to: Msg of 10 Jul 1986 11:50-EDT from Michael van Biema <MICHAEL at CS.COLUMBIA.EDU>
Let me hazard a guess that if you implmented only what is required to be
present a legal Common Lisp and that if you were willing to give up a
LOT of performance for compactness, you could probably pack the code
into 256K bytes and perhaps 128K. This does not count any space for
user-stuff, however. It assumes that you design a special byte-code
with code-density in mind, and that you hand-code an interpreter for
this byte-code.
Such a system would not be very useful, of course. It would be slower
than a less compact interpreter on the same machine by at least a factor
of 10, and would be pretty useless without any environment stuff around.
For a more reasonable implementation, I think that 1 Mbyte is a good
figure to use as the minimum size of a complete Common Lisp and a little
bit of space for user code, not counting the compiler or editor. This
may be more or less, depending on the machine's instruction set.
For those of you who like to point to such numbers as evidence that
Common Lisp as a huge, bloated language, remember that 1 Mbyte is now 8
chips (plus a couple more for ECC).
-- Scott
∂10-Jul-86 1320 LOOSEMORE@UTAH-20.ARPA extra lambda list keywords
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 10 Jul 86 13:20:25 PDT
Date: Thu 10 Jul 86 14:18:40-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: extra lambda list keywords
To: common-lisp@SU-AI.ARPA
Message-ID: <12221637274.15.LOOSEMORE@UTAH-20.ARPA>
I just noticed the bit on p. 65 of the manual where it says:
"Implementations of Common Lisp are free to provide additional lambda-list
keywords."
Is this *really* useful to any implementation? Although you can supposedly
find out about the additional keywords from the lambda-list-keywords constant,
allowing implementation-specific crud to appear in lambda lists seems like
another good way to frustrate would-be implementors of portable code walkers.
In particular, I'm concerned that if implementations try to extend the syntax
of what can appear in lambda lists, code walkers would have a very hard time
identifying default values and other bits of evaluable code in the lambda
list. Not to mention that a routine that tries to parse lambda lists could
get very confused if, for example, it found a strange keyword &foo sitting
where it expected to find only an &rest or &key.
-Sandra
-------
∂10-Jul-86 1414 DCP@STONY-BROOK.SCRC.Symbolics.COM extra lambda list keywords
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Jul 86 14:14:17 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52332; Thu 10-Jul-86 17:08:35 EDT
Date: Thu, 10 Jul 86 17:08 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: extra lambda list keywords
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <12221637274.15.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860710170819.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu 10 Jul 86 14:18:40-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
I just noticed the bit on p. 65 of the manual where it says:
"Implementations of Common Lisp are free to provide additional lambda-list
keywords."
Is this *really* useful to any implementation? Although you can supposedly
find out about the additional keywords from the lambda-list-keywords constant,
allowing implementation-specific crud to appear in lambda lists seems like
another good way to frustrate would-be implementors of portable code walkers.
In particular, I'm concerned that if implementations try to extend the syntax
of what can appear in lambda lists, code walkers would have a very hard time
identifying default values and other bits of evaluable code in the lambda
list. Not to mention that a routine that tries to parse lambda lists could
get very confused if, for example, it found a strange keyword &foo sitting
where it expected to find only an &rest or &key.
What's this talk about portable code walkers. You can't write portable
code at all if you use implementation-specific lambda-list keywords, let
alone portable code walkers.
Historically, I think LispMs did (some may still) have lambda list
keywords &SPECIAL and &LOCAL, whose effects are somewhat obvious by
their names. There was also "E, which effectively defined a special
form, because the argument was automatically quoted. There was also an
&FUNCTIONAL which I think was like "E except that it wasn't quoted
as data, it was quoted as a function. For example, this is how it soft
of behaved:
(defun foo1 ("e bar1 &functional baz1)
(list bar1 baz1))
(foo1 car cdr) =more-or-less= (list 'car #'cdr)
There was also a &LIST-OF for macros. See some old LispM documentation
if you really care.
The above may not be completely accurate, but you get the idea. I agree
that extending lambda-list keywords should be done carefully and for
very good reasons.
∂10-Jul-86 1440 FAHLMAN@C.CS.CMU.EDU extra lambda list keywords
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Jul 86 14:35:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 10 Jul 86 17:35:44-EDT
Date: Thu, 10 Jul 1986 17:35 EDT
Message-ID: <FAHLMAN.12221651295.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: extra lambda list keywords
In-reply-to: Msg of 10 Jul 1986 16:18-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
The option to include additional lambda-list keywords may or may not be
a good idea, but it certainly is not an issue for someone implementing a
portable code walker. Portable code walkers would only work on portable
code, and that would not contain any such extensions.
-- Scott
∂10-Jul-86 1545 LOOSEMORE@UTAH-20.ARPA portable code walkers vs. portable code
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 10 Jul 86 15:45:27 PDT
Date: Thu 10 Jul 86 16:43:43-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: portable code walkers vs. portable code
To: common-lisp@SU-AI.ARPA
Message-ID: <12221663681.27.LOOSEMORE@UTAH-20.ARPA>
Date: Thu, 10 Jul 86 17:08 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
What's this talk about portable code walkers. You can't write portable
code at all if you use implementation-specific lambda-list keywords, let
alone portable code walkers.
Date: Thu, 10 Jul 1986 17:35 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
The option to include additional lambda-list keywords may or may not be
a good idea, but it certainly is not an issue for someone implementing a
portable code walker. Portable code walkers would only work on portable
code, and that would not contain any such extensions.
I must disagree with this sentiment. Perhaps there is is come confusion
between a ((portable code) walker) and a (portable (code walker)). The
issue is not whether or not my program-analyzing program uses nonportable
lambda-list keywords. It's whether my program-analyzing program has to
be able to recognize these beasties in the code it's analyzing.
My contention is that it should be possible to write a portable program to
"walk" *any* valid Common Lisp program. After all, this was the rationale
for prohibiting implementations from defining their own additional special
forms, right? If you allow implementations to extend the syntax of
lambda lists, you might as well let implementations extend the syntax by
introducing more special forms, and let users define their own special
forms too. And once we do that, we might as well forget about having a
standard Lisp dialect in the first place.
As an example of the kind of code walker I had in mind, consider a simple
cross reference utility, something that traverses a function and keeps
track of what other functions it calls. (Perhaps the purpose of the
utility is to locate references to implementation-specific functions.)
As long as I know exactly where evaluable code can or can't validly appear,
I can certainly write this utility in a portable manner, regardless of
whether the bits of code it analyzes are portable or not. However, if
every implementation is free to extend the syntax of the language however
it wants, it would be impossible to write a portable program that checks
for portable usage!
In short, I think it is certainly valid for implementations to include
implementation-specific functions, variables, and macros, (hopefully not
living in the Lisp package), and still call themselves "Common Lisp".
But an implementation that includes syntactic extensions should not call
itself "Common Lisp".
-Sandra
-------
∂10-Jul-86 1705 Masinter.pa@Xerox.COM functionp
Received: from XEROX.COM by SU-AI.ARPA with TCP; 10 Jul 86 17:05:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUL 86 17:05:22 PDT
Date: 10 Jul 86 17:05 PDT
From: Masinter.pa@Xerox.COM
Subject: functionp
To: common-lisp@su-ai.ARPA
Message-ID: <860710-170522-1643@Xerox>
I've been staring at the spec, and I can't see what would prevent a
legitimate implementation from defining functionp from universally
returning T. "functionp is true if its argument is suitable for applying
to arguments". Now,
(lambda (1 2 &nosuchkey) ...) isn't suitable for applying to arguments
in the sense that funcall is guaranteed not to complain about it.
I'm wondering if anyone has any portable code where "functionp" has any
meaningful uses?
∂10-Jul-86 1747 James←W.←Rich.DlosLV@Xerox.COM Re: Editorial Comment
Received: from XEROX.COM by SU-AI.ARPA with TCP; 10 Jul 86 17:47:16 PDT
Received: from Concord.ms by ArpaGateway.ms ; 10 JUL 86 17:46:12 PDT
Sender: "James←W.←Rich.DlosLV"@Xerox.COM
Date: 10 Jul 86 17:46:01 PDT (Thursday)
Subject: Re: Editorial Comment
From: berman@vaxa.isi.EDU
To: jwr.DlosLV@Xerox.COM
cc: common-lisp@SU-AI.Arpa
In-Reply-to: Your message of Tue, 8 Jul 1986 21:32 EDT.
<FAHLMAN.12221170104.BABYL@C.CS.CMU.EDU>
Message-ID: <860710-174612-1703@Xerox>
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
From: berman@vaxa.isi.edu (Richard Berman)
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Re: Editorial Comment
In-Reply-To: Your message of Tue, 8 Jul 1986 21:32 EDT.
<FAHLMAN.12221170104.BABYL@C.CS.CMU.EDU>
Return-Path: <@SU-AI.ARPA:berman@vaxa.isi.edu>
Redistributed: Xerox-Common-Lisp↑.x
Received: from SU-AI.ARPA by Xerox.COM ; 09 JUL 86 10:57:03 PDT
Received: from VAXA.ISI.EDU by SU-AI.ARPA with TCP; 9 Jul 86 10:32:39
PDT
Received: by vaxa.isi.edu (4.12/4.7) id AA25842; Wed, 9 Jul 86 10:32:06
pdt
Message-Id: <8607091732.AA25842@vaxa.isi.edu>
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
Merci.
∂10-Jul-86 1804 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM GC, exit-to-system
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 10 Jul 86 18:03:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39431; Thu 10-Jul-86 20:55:58 EDT
Date: Thu, 10 Jul 86 20:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: GC, exit-to-system
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8607100754.AA08957@ccut.u-tokyo.junet>
Message-ID: <860710205605.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 10 Jul 86 16:54:22+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
In the discussion of our committee,
we wondered why the names of the functions for
gc, and exit to system
are NOT defined in CL.
I am only thinking of the interface naming, not the contents, like editor
interface is defined in CL but the editor subsystem is not defined yet.
I think the unified name for them can be defined in CL.
like,
GC &optional parameters [function]
and
BYE [function]
To give you an example of how much different systems can vary, neither
of these interfaces exist in the Symbolics system. The concept of
exiting to the "system" is not meaningful on Symbolics machines; you're
always in the "system". The concept of calling the GC at a particular
time is not meaningful either; the GC runs in parallel with normal
computation. I'm sure there are other implementations with different
ideas about these concepts. They just don't make very much sense to
standardize, because there is so much variation.
∂10-Jul-86 1928 FAHLMAN@C.CS.CMU.EDU GC, exit-to-system
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Jul 86 19:28:16 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 10 Jul 86 22:28:11-EDT
Date: Thu, 10 Jul 1986 22:28 EDT
Message-ID: <FAHLMAN.12221704534.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: GC, exit-to-system
In-reply-to: Msg of 10 Jul 1986 20:56-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I've been thinking about the GC issue since it first came up. Even
though systems differ tremendously in what GC means to them, it might
make sense to provide a portable GC construct for use in portable code.
This would say that IF the implementation ever needs to do a time
consuming GC operation, this is the time to do it; if that doesn't make
sense in a given implementation, this would be a no-op. This would be
used in portable code that runs benchmarks, for example, to start the
system in as fresh a state as possible. It might also be used when a
program wants to initiate some short real-time operation that should not
be interrupted for GC once it has started. It's not useful for
everyone, but is useful in many systems and does not harm the rest.
I am somewhat more doubtful about the usefulness of BYE in any sort of
portable code. One could argue that it would give users a standard way
of getting out of Lisp on any system where that makes sense, and that it
always is best to have recognizable signs on the emergency exits.
-- Scott
∂10-Jul-86 2201 raible@AMES-NAS.ARPA please add me
Received: from AMES-NAS.ARPA by SU-AI.ARPA with TCP; 10 Jul 86 22:01:46 PDT
Message-Id: <8607101909.AA09830@ames-nas.ARPA>
Received: from localhost by ames-nas.ARPA; Thu, 10 Jul 86 12:09:23 pdt
To: common-lisp@su-ai.ARPA
Subject: please add me
Date: 10 Jul 86 12:09:19 PDT (Thu)
From: raible@AMES-NAS.ARPA
just onother brain-damaged request...
raible@ames-nas
----------
∂10-Jul-86 2233 franz!fizzy!jkf@kim.Berkeley.EDU Re: GC, exit-to-system
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 10 Jul 86 22:33:21 PDT
Received: by kim.Berkeley.EDU (5.53/1.14)
id AA20046; Thu, 10 Jul 86 22:33:32 PDT
From: franz!fizzy!jkf@kim.berkeley.edu
Received: from fizzy by franz (5.5/3.14)
id AA17044; Thu, 10 Jul 86 22:25:52 PDT
Received: by fizzy (4.12/3.14)
id AA04054; Thu, 10 Jul 86 22:25:33 pdt
Return-Path: <fizzy!jkf>
Message-Id: <8607110525.AA04054@fizzy>
To: David A. Moon <ucbkim!STONY-BROOK.SCRC.Symbolics.COM!Moon>
Cc: common-lisp@su-ai.arpa
Subject: Re: GC, exit-to-system
In-Reply-To: Your message of Thu, 10 Jul 86 20:56:00 EDT.
<860710205605.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 10 Jul 86 22:25:30 PDT
>> From: David Moon
>> ...
>> The concept of calling the GC at a particular
>> time is not meaningful either; the GC runs in parallel with normal
>> computation. I'm sure there are other implementations with different
>> ideas about these concepts. They just don't make very much sense to
>> standardize, because there is so much variation.
I think that you may have missed the point. There are certain
functions performed by many (but perhaps not all) of the
implementations of common lisp. Such functions include stopping
a computation and performing a garbage collection, and exiting to the
operating system. It would be a good thing if the names for these
functions were the same across all common lisps where such
functionality exists.
- john foderaro
Franz Inc.
∂10-Jul-86 2248 masinter.PA@Xerox.COM Re: GC, exit-to-system
Received: from XEROX.COM by SU-AI.ARPA with TCP; 10 Jul 86 22:47:59 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 10 JUL 86 22:46:50 PDT
From: masinter.PA@Xerox.COM
Date: 10 Jul 86 22:46:19 PDT
Subject: Re: GC, exit-to-system
In-reply-to: FAHLMAN@C.CS.CMU.EDU's message of Thu, 10 Jul 86 22:28 EDT,
<FAHLMAN.12221704534.BABYL@C.CS.CMU.EDU>
To: FAHLMAN@C.CS.CMU.EDU
cc: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>, common-lisp@SU-AI.ARPA
Message-ID: <860710-224650-1865@Xerox>
Instead of "GC", call it "MAKE-ROOM" and put it in the spec next to
"ROOM". It can be as wonderfully vague:
make-room &optional x [Function]
If the lisp system has any activity it can perform which increases the
amount of storage available by collecting unused structures, do so now.
The nature of this activity is implementation-dependent.
(make-room nil) performs a minimal amount of activity.
(make-room t) performs a maximal amount of useful activity.
Simply (make-room) performs an intermediate amount of collection
activity.
(see p 442).
As far as exit/bye/quit, I'd put it in the section on "The Top-Level
Loop" (pp 324-325)
bye (or whatever) [Function]
The function bye causes the current invocation of whatever "top level
read-eval-print loop" is being executed to be terminated. On some
systems, this will mean "exit to the operating systems"; on others, it
will merely terminate the current process.
- - - - - - - -
Both of these fit in what might more reasonably be called Common Lisp
the Environment rather than Common Lisp the language, but they seem to
have as much of a place as the other items that are in the sections I've
placed them in. Most of these sections don't really correspond to things
that have "semantics" in the traditional sense. They seem most important
for portable programmers rather than portable programs.
∂11-Jul-86 0242 @MIT-GOLDILOCKS.ARPA:SR.LAURITZEN@SPEECH.MIT.EDU compiler-let
Received: from MIT-GOLDILOCKS.ARPA by SU-AI.ARPA with TCP; 11 Jul 86 02:40:49 PDT
Received: from KOALA.MIT.EDU by MIT-GOLDILOCKS.ARPA via CHAOS with CHAOS-MAIL id 2813; Fri 11-Jul-86 05:41:15-EDT
Date: Fri, 11 Jul 86 05:41 EDT
From: Niels Lauritzen <SR.LAURITZEN@SPEECH.MIT.EDU>
Subject: compiler-let
To: common-lisp@SU-AI.ARPA, SR.LAURITZEN@SPEECH.MIT.EDU
Message-ID: <860711054113.2.LAURITZEN@KOALA.MIT.EDU>
If you object to the reference to compilers in COMPILER-LET
how about naming it...
MACROEXPAND-LET since both the interpreter
and the compiler have a macroexpansion phase and these bindings
may affect macroexpansion. (not to be confused with MACROLET)
or (not so good)
EARLY-LET because it binds before evaluation time
in both the interpreter and the compiler.
I certainly don't think that we should do away with
the functionality of MACROLET and COMPILER-LET.
They both are useful for hacking fancy macroexpansion environments.
Now I propose another form to round out the "binding" family
MACROEXPAND-FLET. Use it to define functions that are only used
during the dynamic extent of macroexpansion.
we have
DEFVAR define a global, dynamically scoped variable
DEFUN define a global function
DEFMACRO define a global macro
LET establish a lexically scoped variable,
or bind a dynamically scoped variable
FLET establish a lexically scoped function
(in an intermediate category)
MACROLET establish a lexically scoped macro
MACROEXPAND-LET (was COMPILER-LET)
macroexpand time binding of a variable (dynamic scoping)
MACROEXPAND-FLET
macroexpand time binding of a function (dynamic scoping)
MACROEXPAND-LET* would be icing on the cake because the same effect
could be achieved by using a series of nested MACROEXPAND-LETs.
It seems to me (pardon me if I'm all wet) that because of the way
macroexpansion is done (recursively),
we don't need to distinguish between lexical and dynamic scoping of a macro.
The environment of definition is always the same as the environment of the caller.
So we don't need separate forms for
MACROEXPAND-MACROLET
macroexpand time binding of a macro (dynamic scoping),
because it would be the same as MACROLET,
or a lexically-scoped MACROEXPAND-LET or lexically-scoped MACROEXPAND-FLET.
∂11-Jul-86 0651 smh@mit-ems.ARPA Re: portable code walkers vs. portable code
Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 11 Jul 86 06:51:49 PDT
Received: by mit-ems.ARPA (4.12/4.8) id AA04885; Fri, 11 Jul 86 09:49:58 edt
Date: Fri, 11 Jul 86 09:49:58 edt
From: Steven Haflich <smh@mit-ems.ARPA>
Message-Id: <8607111349.AA04885@mit-ems.ARPA>
To: LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
Subject: Re: portable code walkers vs. portable code
> From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
> My contention is that it should be possible to write a portable program to
> "walk" *any* valid Common Lisp program.
Agreed.
> But an implementation that includes syntactic extensions should not call
> itself "Common Lisp".
An *implementation* can provide anything it likes. Provided it is
provably upward compatible with "Common Lisp", it is a valid Common
Lisp. However, any *program* which uses these extensions cannot
correctly be called a "Common Lisp program". A portable Common Lisp
code walker will work only for Common Lisp code.
This distinction is important if we are ever to nail down what is a
legitimate Common Lisp and what isn't.
> After all, this was the rationale for prohibiting implementations from
> defining their own additional special forms, right? If you allow
> implementations to extend the syntax of lambda lists, you might as well
> let implementations extend the syntax by introducing more special
> forms, and let users define their own special forms too.
Implementations are free to provide additional special forms provided
they also make available macro equivalents. Additional special forms
are no problem for code walkers. (Provided the macro equivalents
really are functionally [sic] equivalent...)
Your argument is still a good one, that extending the syntax of lisp
forms makes impossible portable code analysis tools. This should not
be done lightly, but it doesn't invalidate a Common Lisp.
∂11-Jul-86 0715 greek%bach.DEC@decwrl.DEC.COM Our MUFCSPC entry.
Received: from DECWRL.DEC.COM by SU-AI.ARPA with TCP; 11 Jul 86 07:15:45 PDT
Received: from DEC-RHEA.ARPA (dec-rhea) by decwrl.DEC.COM (4.22.05/4.7.34)
id AA10020; Fri, 11 Jul 86 07:17:10 pdt
Message-Id: <8607111417.AA10020@decwrl.DEC.COM>
Date: Friday, 11 Jul 1986 07:16:04-PDT
From: greek%bach.DEC@decwrl.DEC.COM (What have I done?)
To: common-lisp@su-ai, rich%bach.DEC@decwrl.DEC.COM
Subject: Our MUFCSPC entry.
We think the following pretty-printer for DO is pretty cute. Of course, one
could say that we have an unfair perspicuity advantage since we've extended
FORMAT to do pretty-printing.
(define-list-print-function do (list stream)
(format stream "~1!~W~↑ ~:I~@←~/sys::bind-list/~↑ ~←~
~1!~↑~W~↑ ~←~W~↑~@{~%~W~↑~}~.~
~1I~@{~↑~%~W~}~."
list))
Just in case you're wondering what the ~/SYS::BIND-LIST/ directive is:
(define-format-directive sys::bind-list (list stream colon-p atsign-p)
(declare (ignore atsign-p colon-p))
(format stream "~1!~@{~1!~W~↑ ~:I~@←~@{~W~↑ ~:←~}~.~↑ ~%~}~." list))
Special thanks to Dick Waters.
- Paul & Rich
∂11-Jul-86 0728 shebs%utah-orion@utah-cs.arpa Re: GC, exit-to-system
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 11 Jul 86 07:27:32 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA07922; Fri, 11 Jul 86 08:24:01 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA01909; Fri, 11 Jul 86 08:23:57 MDT
Date: Fri, 11 Jul 86 08:23:57 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8607111423.AA01909@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: GC, exit-to-system
Summary:
Expires:
References: <FAHLMAN.12221704534.BABYL@C.CS.CMU.EDU>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <FAHLMAN.12221704534.BABYL@C.CS.CMU.EDU> Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) writes:
>
>I've been thinking about the GC issue since it first came up. Even
>though systems differ tremendously in what GC means to them, it might
>make sense to provide a portable GC construct for use in portable code.
I agree. Perhaps something more generic like CLEAN-STATE would be
appropriate - it could do whatever "freshening up" might be appropriate,
such as handling all pending interrupts or rehashing of internal tables
or whatever other exotic things implementations might be doing concurrently
with computation.
>I am somewhat more doubtful about the usefulness of BYE in any sort of
>portable code. One could argue that it would give users a standard way
>of getting out of Lisp on any system where that makes sense, and that it
>always is best to have recognizable signs on the emergency exits.
If one were to argue against BYE, then one would also have to flush
ED and ROOM and all other things that are required, but whose operation
is highly unspecified. Along the same lines, it might make sense to
require that an implementation should have a world dumper called
SAVE-SYSTEM that takes a filename and puts in the file a copy of the
lisp such that when it is restored (by unspecified means) you are
in the state just before the SAVE-SYSTEM was done. This is something
almost every Lisp provides, but with wildly varying details. It would
of course be OK to have lots of extra keywords on such a function, but
a portable implementation of an embedded language can just supply the
filename to SAVE-SYSTEM and expect it to work almost everywhere.
stan
∂11-Jul-86 0815 FAHLMAN@C.CS.CMU.EDU compiler-let
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Jul 86 08:14:31 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 11 Jul 86 11:14:43-EDT
Date: Fri, 11 Jul 1986 11:14 EDT
Message-ID: <FAHLMAN.12221844073.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: compiler-let
In reply to: Niels Lauritzen <SR.LAURITZEN at SPEECH.MIT.EDU>
Now I propose another form to round out the "binding" family
MACROEXPAND-FLET. Use it to define functions that are only used
during the dynamic extent of macroexpansion.
MACROEXPAND-LET* would be icing on the cake because the same effect
could be achieved by using a series of nested MACROEXPAND-LETs.
MACROEXPAND-MACROLET
macroexpand time binding of a macro (dynamic scoping),
COMPILER-LET (or MACROEXPAND-LET, if you prefer) is of very marginal
benefit, if any. If people feel that such a thing must be fully rounded
out for reasons of symmetry, I say we should flush the whole thing.
I also feel that it was a major mistake letting MACROLET in, but I've
already lost that battle twice and don't plan to fight it again.
-- Scott
∂11-Jul-86 0858 FAHLMAN@C.CS.CMU.EDU GC, exit-to-system
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Jul 86 08:58:47 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 11 Jul 86 11:28:23-EDT
Date: Fri, 11 Jul 1986 11:27 EDT
Message-ID: <FAHLMAN.12221846475.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: masinter.PA@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Subject: GC, exit-to-system
I agree that many of these functions (BYE, ROOM, ED) are more for
portable programmers than for portable programs. That doesn't mean that
they are a bad thing; it just means that we have to carefully indicate
what they are and are not required to do and what happens on systems
where they make no sense. It's nice to be able to go up to a strange
Common Lisp and know in general how to do the most important top-level
things. GC is perhaps unusual, since it does have some uses in code, as
several of us have indicated.
As to your specific proposed changes, I don't like either of them.
What's wrong with calling the GC function "GC"? Most Common Lisps
already support this, and call it "GC". (Systems could define their own
keyword arguments for this to get more subtle system-dependent effects.)
As for "BYE", I think that it should be documented as leaving the Lisp
altogether, if that makes sense. Bringing in the idea of leaving the
current top-level loop complicates things immensely because it interacts
with nested break levels and stack groups and all sorts of other
non-standard things.
-- Scott
∂11-Jul-86 0935 gls@Think.COM portable code walkers vs. portable code
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 11 Jul 86 09:35:31 PDT
Received: from botolph by Godot.Think.COM via CHAOS; Fri, 11 Jul 86 12:35:29 edt
Date: Fri, 11 Jul 86 12:36 EDT
From: Guy Steele <gls@Think.COM>
Subject: portable code walkers vs. portable code
To: LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <12221663681.27.LOOSEMORE@UTAH-20.ARPA>
Message-Id: <860711123622.2.GLS@BOTOLPH.THINK.COM>
Date: Thu 10 Jul 86 16:43:43-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
...
As an example of the kind of code walker I had in mind, consider a simple
cross reference utility, something that traverses a function and keeps
track of what other functions it calls. (Perhaps the purpose of the
utility is to locate references to implementation-specific functions.)
As long as I know exactly where evaluable code can or can't validly appear,
I can certainly write this utility in a portable manner, regardless of
whether the bits of code it analyzes are portable or not. However, if
every implementation is free to extend the syntax of the language however
it wants, it would be impossible to write a portable program that checks
for portable usage!
That is correct. But observe that an implementation is free to add new data
types, and is free to make those data types mean something to the evaluator
(see CLtL, pp. 54-55). For example, I might extend my Common Lisp to
evaluate a vector by evaluating its elements in parallel and returning the
value of just one of them (implemented by choosing the value of whichever
one finishes first). I might introduce a new data type called a mote that
is written as an Internet host number, an underscore, and a digit sequence
(swiping some of the namespace for potential numbers). A mote can serve as
an identifier, much like a symbol, but is shared among all processes on the
network and resides in the specified host. I can let another host know
when I am running ZORK by writing
(defun zork ()
(let ((192.5.100.2←569 t)) ;bind mote 569 in host 192.5.100.2
...
))
Indeed, a (portable (code walker)) cannot hope to deal with such extensions.
The intent of LAMBDA-LIST-KEYWORDS was simply to give a code walker a
fighting chance at deciding whether or not something screwy was going on,
and if so, how screwy it could be.
--Guy
∂11-Jul-86 1000 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Re: GC, exit-to-system
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 11 Jul 86 09:59:18 PDT
Received: from utokyo-relay by csnet-relay.csnet id ah19462; 11 Jul 86 12:41 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA29922; Fri, 11 Jul 86 15:32:59+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA27740; Fri, 11 Jul 86 15:18:28+0900
Date: Fri, 11 Jul 86 15:18:28+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607110618.AA27740@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA
Subject: Re: GC, exit-to-system
>Date: Thu, 10 Jul 1986 22:28 EDT
>Message-Id: <FAHLMAN.12221704534.BABYL@C.CS.CMU.EDU>
>From: "Scott E. Fahlman" <Fahlman%C.CS.CMU.EDU@u-tokyo.junet>
>To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
>Cc: common-lisp@SU-AI.ARPA
>Subject: GC, exit-to-system
>In-Reply-To: Msg of 10 Jul 1986 20:56-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
>Received: from CSNet-Relay by utokyo-relay; 11 Jul 86 13:34:26-JST (Fri)
>Status: R
>
>
>I've been thinking about the GC issue since it first came up. Even
>though systems differ tremendously in what GC means to them, it might
>make sense to provide a portable GC construct for use in portable code.
>This would say that IF the implementation ever needs to do a time
>consuming GC operation, this is the time to do it; if that doesn't make
>sense in a given implementation, this would be a no-op. This would be
>used in portable code that runs benchmarks, for example, to start the
>system in as fresh a state as possible. It might also be used when a
>program wants to initiate some short real-time operation that should not
>be interrupted for GC once it has started. It's not useful for
>everyone, but is useful in many systems and does not harm the rest.
>
Yes! this is just the story we are talking.
>I am somewhat more doubtful about the usefulness of BYE in any sort of
>portable code. One could argue that it would give users a standard way
>of getting out of Lisp on any system where that makes sense, and that it
>always is best to have recognizable signs on the emergency exits.
>
I also think BYE is not so useful in portable codes.
BYE came from the discussion on a tutorial for the novices.
It may be useful for the general training cource without Lisp machine.
If we teach a new subsystem under a operating system in my university,
at least I, first, teach how to enter the subsystem and
teach how to exit from it with no other operations. After that,
I will start the main menu.
>-- Scott
>
>
ida
∂11-Jul-86 1038 liz@brillig.umd.edu portable code walkers
Received: from BRILLIG.UMD.EDU by SU-AI.ARPA with TCP; 11 Jul 86 10:38:19 PDT
Received: by brillig.umd.edu (5.9/4.7) id AA08321; Fri, 11 Jul 86 13:39:04 EDT
Message-Id: <8607111739.AA08321@brillig.umd.edu>
To: common-lisp@su-ai.arpa
Subject: portable code walkers
Date: Fri, 11 Jul 86 13:39:03 -0500
From: Liz Allen <liz@brillig.umd.edu>
We did code walking in a simple way for our flavors implementation
in Franz using their macroexpand function. The Franz macroexpand
expands more than just the top level form; it finds all subforms
that will be evaluated and expands any macros found there as well
-- basically, it does a code walk. We had to fix it (since it
didn't know about all the special forms in Franz). We then modified
it so it takes an optional argument that is a function. That
function is applied to every subform that will be eval'd after it
has been completely macroexpanded. The value returned by that
function is used in place of the form. I would like to propose
something similar here:
---------------
CODE-WALK form &optional function [ function ]
For the form given, this expands all the macros at the top level,
determines which subforms will be eval'd and calls itself recursively
on those subforms consing up the equivalent form from the values
given. If the optional function is given, after all the subforms
are expanded (in each recursive call), the function is called and
passed the new form and substitutes the value returned for that
form.
For example, given:
(defun hack-ivar-refs (form)
(cond ((ivarp form) `(get-ivar ,form self))
((and (listp form)
(eq (car form) 'setq)
(ivarp (cadr form)))
;; being lazy -- assuming only 2 args to setq
`(set-ivar ,(cadr form) self ,(caddr form)))
(t form)))
a call like (code-walk form #'hack-ivar-refs) will find all the
references to the instance variables that need to be found and
replaced by the appropriate calls to get and set their values.
-----
This took care of what we needed to do for our flavors implementation
quite nicely. I'm not sure if there are code walking situations
that would require greater functionality... It is possible that
someone would like to have hooks to look at the forms before they
are macroexpanded or perhaps even after each macro is expanded;
both of those two things could be handled easily.
Comments?
-Liz
∂11-Jul-86 1057 LOOSEMORE@UTAH-20.ARPA Re: portable code walkers vs. portable code
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 11 Jul 86 10:57:03 PDT
Date: Fri 11 Jul 86 11:54:52-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: Re: portable code walkers vs. portable code
To: gls@ZARATHUSTRA.THINK.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860711123622.2.GLS@BOTOLPH.THINK.COM>
Message-ID: <12221873242.30.LOOSEMORE@UTAH-20.ARPA>
Bleah.... Defining new evaluable objects opens up a whole can of worms
that I don't even want to *think* about. (I would personally be happier
if things like vectors that are subtypes of common were defined to be
self-evaluating objects, and leave implementation-specific datatypes to
have implementaton-specific meanings....)
Fortunately CLtL is fairly concise about defining what forms are valid in
all implementations, so a code walker could indeed detect this kind of
non-standard usage. Likewise, a code walker could detect when you
reference a non-standard lambda keyword (but probably not detect
non-standard syntax for supplying defaults or whatever in the lambda
list). The thing that really bothers me, though, is the possibility that a
((portable code) walker) could fail to process a piece of portable code
because the implementation saw fit to expand a standard macro into
something that contains references to implementation-specific syntax
extensions, such as new special forms, nonstandard forms, and strange
lambda list syntax. As the manual stands now (p 58), it at least
*mentions* that implementors should avoid the first two, but doesn't say
anything about avoiding lambda list syntax extensions in this situation.
I'm all for making the warning a bit stronger and prohibiting all three
cases.
-Sandra
-------
∂11-Jul-86 1546 Masinter.pa@Xerox.COM Re: portable code walkers
Received: from XEROX.COM by SU-AI.ARPA with TCP; 11 Jul 86 15:46:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 86 15:46:22 PDT
Date: 11 Jul 86 15:46 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: portable code walkers
In-reply-to: Liz Allen <liz@brillig.umd.edu>'s message of Fri, 11 Jul 86
13:39:03 -0500
To: liz@brillig.umd.edu
cc: common-lisp@su-ai.arpa
Message-ID: <860711-154622-2562@Xerox>
There's a portable code-walker which is part of Portable CommonLoops
which does just what you want. The entry point is
(walk-form form &key walk-function declarations lexical-variables
environment lexical-variables)
The walk-function is like your optional function but it can return a
second value that says whether or not to re-walk; the other keywords are
if you want to pass in some of the other information that the walker
keeps track of.
The code & documentation for it is part of the Portable CommonLoops
release. ("Copyright (c) 1985 Xerox Corporation. All rights reserved.
Use and copying of this software and preparation of derivative works
based upon this software are permitted. ...")
I have portable implementations of macrolet, flet, labels, and
compiler-let using the portable code-walker, e.g.
(defmacro compiler-let (vars &rest forms &environment env)
(eval `(special-let ,vars (walk-form `(progn ,@forms) :environment
env))))
where special-let is a macro that expands to a let with all of the
variables declared special. This says to expand all of the macros in
forms while the variables are bound.
∂11-Jul-86 1601 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM portable code walkers vs. portable code
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 11 Jul 86 16:00:53 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39571; Fri 11-Jul-86 10:21:14 EDT
Date: Fri, 11 Jul 86 10:27 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: portable code walkers vs. portable code
To: LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <12221663681.27.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860711102726.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu 10 Jul 86 16:43:43-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
My contention is that it should be possible to write a portable program to
"walk" *any* valid Common Lisp program. After all, this was the rationale
for prohibiting implementations from defining their own additional special
forms, right? If you allow implementations to extend the syntax of
lambda lists, you might as well let implementations extend the syntax by
introducing more special forms, and let users define their own special
forms too. And once we do that, we might as well forget about having a
standard Lisp dialect in the first place.
The issue hinges on what the phrase "valid Common Lisp program" means.
The intention of the manual is that any implementation may put in
various extensions, but a valid Common Lisp program does not use any
such extensions.
Regarding code walkers, there was an attempt made to allow code walkers
to work not only on valid Common Lisp programs, but even on programs
that go outside the bounds of Common Lisp. This attempt is the reason
for the magic list of special forms, and that idea that any new special
form should have a translator, etc. As has been discussed in this
mailing list previous, it's not at all clear that this attempt works, or
can possibly work. You are correct in pointing out that the attempt
certainly cannot work if implementations have extra lambda-list
keywords. However, I think that we had already established that the
attempt could not work, anyway, for other reasons.
Your final contention is not true. If we let implementations put in
their own special forms, that does not in any way prevent us from having
a common subset that is shared among all these implementations. That is
what Common Lisp is, and that's why it's called Common Lisp. It does
mean that you can't write a portable code-walker capable of
understanding any program in any extended dialect that contains Common
Lisp as a subset, which doesn't seem very surprising. You can still
write a code walker that's fully portable and can be guaranteed to work
on any valid Common Lisp program, which means any program written
completely within the common subset.
∂11-Jul-86 1601 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM functionp
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 11 Jul 86 16:00:59 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39569; Fri 11-Jul-86 10:13:13 EDT
Date: Fri, 11 Jul 86 10:19 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: functionp
To: Masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <860710-170522-1643@Xerox>
Message-ID: <860711101909.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 10 Jul 86 17:05 PDT
From: Masinter.pa@Xerox.COM
I've been staring at the spec, and I can't see what would prevent a
legitimate implementation from defining functionp from universally
returning T. "functionp is true if its argument is suitable for applying
to arguments". Now,
If in some implementation (functionp 3) returned T, I would not call
that legitimate.
(lambda (1 2 &nosuchkey) ...) isn't suitable for applying to arguments
in the sense that funcall is guaranteed not to complain about it.
It all depends on what you mean by "suitable for applying to arguments",
which is admittedly a pretty vague phrase. How about a compiled code
object in which there was a compiler bug that caused the argument-taking
instructions to not be compiled quite right? What about
(defun foo (&optional (x (/ 1 0))) x), which will signal an error during
the argument-passing process if x is not provided?
I'm wondering if anyone has any portable code where "functionp" has any
meaningful uses?
The Symbolics software environment uses it in about 35 places. I just
looked at a few. In several cases, it's being used to provide error
checking, so that the user will get an error message that says "hey,
that should have been a function, but isn't" as early as possible,
rather than finding out much later when it's harder to debug. In cases
like the one you present, the user will just find out later, when it's
harder to debug, but at least the functionp will accomplish its purpose
for the vast majority of cases.
In some of the other usages, it's part of what amounts to a user
interface in a software tool, or a facility that does one thing when
given a "function" and another when given a number, or something like
that. These uses can indeed be somewhat heuristic, in that ambiguous
cases are constructable, but in practice this does not seem to be a big
problem.
∂11-Jul-86 1822 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM GC, exit-to-system
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 11 Jul 86 18:22:10 PDT
Received: from OWL.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 40064; Fri 11-Jul-86 21:23:14 EDT
Date: Fri, 11 Jul 86 21:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: GC, exit-to-system
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: masinter.PA@XEROX.COM, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12221846475.BABYL@C.CS.CMU.EDU>
Message-ID: <860711212151.7.MOON@OWL.SCRC.Symbolics.COM>
(defun bye ()
(si:halt "Shutdown yes
"))
I think I had better not install this, though. It powers off the machine.
∂11-Jul-86 1843 Pavel.pa@Xerox.COM Re: DECLARE SPECIAL Considered Confusing
Received: from XEROX.COM by SU-AI.ARPA with TCP; 11 Jul 86 18:43:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 86 18:43:39 PDT
Date: 11 Jul 86 18:43 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: DECLARE SPECIAL Considered Confusing
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 7 Jul 86 23:13 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <860711-184339-1110@Xerox>
In this message I will give a complete description of my proposal for
declaration scoping. I won't attempt to argue for it on the basis of
``obviousness'' or clarity, though, because I think that there are
people who find each of the two ways of scoping special declarations
confusing. Rather, I like this way of doing things because it satisfies
an important (to me) consistency criterion: the scope of \any/
declaration coincides with a particular lexical identifier scope.
There are six primitive forms in Common Lisp that can both bind
identifiers and carry declarations:
LET LET* FLET LABELS MACROLET LAMBDA
I will describe the scoping rules for declarations in each of these
forms.
LET
The scope of the declarations within a LET is precisely the scope of the
variables being bound. That is, any declarations within a LET affect
all of the bindings themselves and all forms appearing within the scope
of those bindings. Because the various initial-value expressions for
the bindings are not evaluated within the scope of those bindings,
neither are the declarations in effect over those expressions. Thus, in
the form below,
(let ((<var-1> <expr-1>)
...
(<var-n> <expr-n>))
<declarations>
<body-forms>
)
the given <declarations> affect the bindings of <var-1> through <var-n>
and the <body-forms>, but not <expr-1> through <expr-n>.
LET*
The LET* special form is most easily understood as a series of nested
LET's. The question is, how are the declarations to be distributed
among those various nested scopes? The answer is to leave almost all of
the declarations in the innermost LET and to distribute to each of the
other scopes only those declarations that could apply to the variable
being bound there. Thus, the following LET*:
(let* ((a <init-a>)
(b <init-b>)
(c <init-c>))
(declare (special a b c)
(inline foo)
(optimize (speed 3))
(type (integer 0 *) b))
<body-forms>
)
is equivalent to this set of nested LET's:
(let ((a <init-a>))
(declare (special a))
(let ((b <init-b>))
(declare (special b)
(type (integer 0 *) b))
(let ((c <init-c>))
(declare (special c)
(inline foo)
(optimize (speed 3))
<body-forms>
)))
FLET
This is simply a syntactically pleasing way to lexically bind functions
to identifiers appearing in functional position. Thus, we should think
of the following FLET:
(flet ((<var-1> (<args-1>) <body-1>)
...
(<var-n> (<args-n>) <body-n>))
<declarations>
<body-forms>
)
as this LET:
(let ((<var-1> #'(lambda (<args-1>) <body-1>))
...
(<var-n> #'(lambda (<args-n>) <body-n>)))
<declarations>
<body-forms>
)
except that the <var-i> are bound as function identifiers instead of as
variables. The scope of the declarations thus includes the <body-forms>
but none of the <args-i> or <body-i>.
LABELS
This is a version of FLET that differs only in the scope of the bindings
of the names for the functions. Thus, the scope of the declarations
should be the same as in FLET except for those applicable to the
bindings themselves, which should cover the entire construct.
MACROLET
The scoping here is precisely as in FLET, covering the bindings of the
macros (whatever that might mean) and the body of the form, but not the
bodies of the macros themselves.
LAMBDA
The scope of the first required parameter in a LAMBDA covers all other
bindings and code within the LAMBDA form. The declarations have the
very same scope, covering all executable code within the form. (In the
case where no required parameters exist, the declarations still cover
the whole form, the scope of a new, imaginary, required parameter.
==========
I believe that this proposal is consistent and relatively easy to
reconstruct from the simple principle that the scope of a declaration is
always the lexical scope of some identifier.
Thoughts?
Pavel
∂11-Jul-86 2019 FAHLMAN@C.CS.CMU.EDU DECLARE SPECIAL Considered Confusing
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Jul 86 20:19:40 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 11 Jul 86 23:19:50-EDT
Date: Fri, 11 Jul 1986 23:19 EDT
Message-ID: <FAHLMAN.12221976083.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: DECLARE SPECIAL Considered Confusing
In-reply-to: Msg of 11 Jul 1986 21:43-EDT from Pavel.pa at Xerox.COM
Thanks for working out a coherent proposal for your proposed changes to
the special declaration scoping rules.
My feeling on this is that any change to the scoping rules is a very big
change: such a change requires a lot of work to fix up existing
implementations, and it has the potential to create a lot of subtle bugs
in existing user code. Maybe in this case it is not quite so serious,
since several implementations are currently incorrect, but still it is a
big alteration in an area that was discussed and settled long ago.
A change of this size should only be made if one of the following
conditions holds:
1. The current situation is inconsistent and untenable.
2. The current situation causes serious trouble in practice for
implementors or code writers.
3. We have nearly unanimous agreement that the new way is enough better
that it is worth the trouble to make the change.
I don't see any evidence for 1 or 2, and as of now I don't hear the kind
of enthusiasm for this change that 3 would require. Then again, I
haven't heard any implementors say they absolutely oppose this change.
-- Scott
∂11-Jul-86 2042 JAR@AI.AI.MIT.EDU DECLARE SPECIAL Considered Confusing
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 11 Jul 86 20:42:00 PDT
Date: Fri, 11 Jul 86 23:10:34 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: DECLARE SPECIAL Considered Confusing
To: Pavel.pa@XEROX.COM
cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of 11 Jul 86 18:43 PDT from Pavel.pa at Xerox.COM
Message-ID: <[AI.AI.MIT.EDU].68800.860711.JAR>
Excellent. This is the closest thing I've seen yet to the right thing,
given CL's political and compatibility constraints.
Jonathan
∂11-Jul-86 2142 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA A minimal Common Lisp interpreter.
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 11 Jul 86 21:42:01 PDT
Received: from utokyo-relay by csnet-relay.csnet id al24876; 12 Jul 86 0:39 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA14429; Sat, 12 Jul 86 13:23:45+0900
From: yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA
Received: by nttlab.ntt.junet (4.12/5.0) with TCP; Sat, 12 Jul 86 12:48:05 jst
Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet)
id AA01353; Fri, 11 Jul 86 20:48:02+0900
Date: Fri, 11 Jul 86 20:48:02+0900
Message-Id: <8607111148.AA01353@kurims.kurims.kyoto-u.junet>
To: MICHAEL%CS.COLUMBIA.EDU%u-tokyo.junet@CSNET-RELAY.ARPA
Subject: A minimal Common Lisp interpreter.
Cc: common-lisp%su-ai.arpa%u-tokyo.junet@CSNET-RELAY.ARPA
This is the information from Kyoto Common Lisp.
KCL is an acronym of Kyoto Common Lisp, but it is also the name of
the full-set version of Kyoto Common Lisp. We also have a subset version
of KCL, called KCN. KCN differs from KCL in that it does not contain
the compiler nor the online documentations. In other respect, KCN is
same as KCL. Its size is 1.26 Mbytes, excluding the user heap but including
the system data. Many functions are written in Common Lisp, though it is
not clear how large is the total size of these functions. The size of KCN
is reduced about 5% on VAX.
-- Taiichi
∂12-Jul-86 0508 DCP@QUABBIN.SCRC.Symbolics.COM Re: GC, exit-to-system
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 12 Jul 86 05:07:53 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 18798; Sat 12-Jul-86 08:06:39 EDT
Date: Sat, 12 Jul 86 08:07 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: GC, exit-to-system
To: franz!fizzy!jkf@kim.berkeley.edu
cc: David A. Moon <Moon@QUABBIN.SCRC.Symbolics.COM>,
common-lisp@SU-AI.ARPA
In-Reply-To: <8607110525.AA04054@fizzy>
Message-ID: <860712080715.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 10 Jul 86 22:25:30 PDT
From: franz!fizzy!jkf@kim.berkeley.edu
>> From: David Moon
>> ...
>> The concept of calling the GC at a particular
>> time is not meaningful either; the GC runs in parallel with normal
>> computation. I'm sure there are other implementations with different
>> ideas about these concepts. They just don't make very much sense to
>> standardize, because there is so much variation.
I think that you may have missed the point. There are certain
functions performed by many (but perhaps not all) of the
implementations of common lisp. Such functions include stopping
a computation and performing a garbage collection,
You missed a subtle point. The LispM systems normal GC stop a
computation only long enough to start the GC. The computation is not
stopped for the performance of the garbage collection. There are a lot
of different levels of GC in our system, perhaps more so than in most.
In theory, you could call
(si:gc-flip-now)
to cause a GC to be started, or
(si:gc-immediately)
which not only starts it, but the code executing it doesn't return until
the GC completes, BUT, other processes are still allowed to run.
(si:full-gc)
stops everybody while it does a massive amount of work. What about the
user interface issues of trying to start a GC when the system is pretty
sure you will run out of room (assuming a copying garbage collector)?
Which of the above functions do you want in the language? Maybe figure
out how to write one function that is completely overloaded? What if
you ask a GC to be started but a GC is already in progress? Do you want
options to say "that's OK, don't do another" and "wait for the current
one and then start a new one"? What about ways to flip ephemeral spaces
in systems that have ephemeral GCs as opposed to flipping dynamic
spaces? I think you want the ability to do both. What about
controlling different forms of ephemeral migration? I know of at least
four possibilities: (1, normal) next level, (2, dynamic) always to
non-ephemeral, (3, keep) lowest ephemeral level flips and is copied back
into the lowest ephemeral level, (4, collect) lowest ephemeral level
doesn't flip, so things tend to collect at the bottom. What about
flipping a subset of "areas" for systems where that is meaningful.
and exiting to the
operating system. It would be a good thing if the names for these
functions were the same across all common lisps where such
functionality exists.
Which functions? I've listed anywhere from 5 to 50 possibilities.
∂12-Jul-86 0536 SARASWAT@C.CS.CMU.EDU KCl vs KCN
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 Jul 86 05:33:26 PDT
Received: ID <SARASWAT@C.CS.CMU.EDU>; Sat 12 Jul 86 08:33:53-EDT
Date: Sat 12 Jul 86 08:33:52-EDT
From: vijay <Vijay.Saraswat@C.CS.CMU.EDU>
Subject: KCl vs KCN
To: common-lisp@SU-AI.ARPA
Message-ID: <12222076950.27.SARASWAT@C.CS.CMU.EDU>
Avoid KCN like the plague. KCl is a salt but KCN kills!! :-)
-------
∂12-Jul-86 0754 franz!fizzy!jkf@kim.Berkeley.EDU Re: GC, exit-to-system
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 12 Jul 86 07:52:07 PDT
Received: by kim.Berkeley.EDU (5.53/1.14)
id AA18962; Sat, 12 Jul 86 07:52:21 PDT
From: franz!fizzy!jkf@kim.berkeley.edu
Received: from fizzy by franz (5.5/3.14)
id AA21491; Sat, 12 Jul 86 07:45:53 PDT
Received: by fizzy (4.12/3.14)
id AA06716; Sat, 12 Jul 86 07:45:31 pdt
Return-Path: <fizzy!jkf>
Message-Id: <8607121445.AA06716@fizzy>
To: David C. Plummer <ucbkim!QUABBIN.SCRC.Symbolics.COM!DCP>
Cc: common-lisp@su-ai.arpa
Subject: Re: GC, exit-to-system
In-Reply-To: Your message of Sat, 12 Jul 86 08:07:00 EDT.
<860712080715.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sat, 12 Jul 86 07:45:28 PDT
On a machine which does real-time garbage collection, a definition
such as
(defun gc () nil)
would be sufficient. If you want to give people control over the
various other types of gc that the lisp machine can do, then write
different functions.
Many people (I'd say 'most' but I don't have the figures at hand to
back it up) use Lisp on stock hardware where a garbage collection does
indeed stop computation for a noticeable period of time. It is for
these systems that the 'gc' function exists.
The gc function is merely a suggestion to the lisp system, if it
can't do a gc, it can ignore the suggestion.
--------
This whole discussion is an example of a bigger issue: there need to
be sub-standards for various subsets of the community. For example,
many (again, perhaps 'most') Lisp users run under the Unix operating
system. Our users want hooks to the unique features of Unix.
While there is a framework for declaring (proclaming?) standards,
there should be a effort made to provide standards for communities of
users.
-john foderaro
Franz Inc.
∂12-Jul-86 1618 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: DECLARE SPECIAL Considered Confusing
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 12 Jul 86 16:18:46 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 40282; Sat 12-Jul-86 19:18:35 EDT
Date: Sat, 12 Jul 86 19:17 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: DECLARE SPECIAL Considered Confusing
To: fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <860712191707.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
I think it's hard to say whether the current situation causes serious
trouble for code writers, or will cause such trouble. I agree with you
that the policy question of whether we should consider the question open
or not is not completely clear. However, I find the current situation
confusing and counterintuitive. Confusing behavior in a peripheral part
of the language definition is one thing, but here we're talking about
confusing in the basic semantics of how variables work. I definitely do
not like the current definition. It seems arbitrary, inconsistent, and
overly complex that the evaluation of certain forms, like optional init
forms, should see the declarations from the body inside while they do
not see the variables being bound. I fully expect to have bugs in my
code because of this surprise, and I don't know if I'll ever get used to
it. I would be happier if we decided to fix the definition in some way
(Pavel's proposal looks like it's basically the right thing, but I have
not thought hard about all the details yet).
∂12-Jul-86 1948 FAHLMAN@C.CS.CMU.EDU DECLARE SPECIAL Considered Confusing
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 Jul 86 19:48:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 12 Jul 86 22:48:30-EDT
Date: Sat, 12 Jul 1986 22:48 EDT
Message-ID: <FAHLMAN.12222232521.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: DECLARE SPECIAL Considered Confusing
It seems that Weinreb and Rees both like Pavel's proposal better than
the status quo, so it is at least worthy of careful consideration. As
an individual, I like the proposal too, except for a couple of problems
that I think I see. I'm not sure whether it is enough of an improvement
to be worth the trouble that such a change would cause, but in the case
of Spice Lisp, our interpeter does not correctly implement the current
rules at present. (Our compiler does.)
Let's explore Pavel's idea, try to get it right, and then see if the
community feels it improves the coherence and consistency of the
langauge enough to be worth the trouble of changing things.
I used to feel that the clearest and simplest way to handle these
embedded declarations was to treat the scope of the declaration form as
wrapping the whole form in which it appeared. Maybe this is an example
of what Moon calls "superficial simplicity". The idea of letting the
scope of each declaration match the scope of the variable it applies to,
with any remaining declarations wrapping only the body of the form, is
perhaps a conceptually clearer way to handle this if we explain it
clearly enough.
I think that Pavel's treatment of LET, LET*, FLET, LABELS, and MACROLET
is good. We would also need to say explicitly that a SPECIAL
declaration for a variable that is not bound by the form in question
wraps only the body, not the init forms.
We would also need to spell out in detail exactly how all this works in
DO, DO*, and friends. It's ovious what should happen if you think in
terms of the expansion into a LET or LET* form, but we don't want to
leave that up to the readers to figure out.
I disagree with Pavel's proposal for LAMBDA (and, therefore, DEFUN). He
suggests that the scope of all the declarations should coincide with the
scope of the first required parameter -- in effect, this follows the
current rule of making the declarations wrap everything. That seems
wrong to me. The variables are bound and the init-forms are computed
left-to-right, as in LET*. If we change LET* in the way Pavel suggests,
we ought to change LAMBDA in the corresponding way: the scope of a
declaration matches the scope of the variable binding it applies to; the
scope of declarations that do not apply to variable-bindings created by
the lambda list includes only the body of the form.
-- Scott
∂12-Jul-86 2142 Pavel.pa@Xerox.COM Re: DECLARE SPECIAL Considered Confusing
Received: from XEROX.COM by SU-AI.ARPA with TCP; 12 Jul 86 21:42:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUL 86 21:42:03 PDT
Date: 12 Jul 86 21:40 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: DECLARE SPECIAL Considered Confusing
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sat,
12 Jul 86 22:48 EDT
To: Fahlman@C.CS.CMU.EDU
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <860712-214203-1410@Xerox>
Date: Sat, 12 Jul 86 22:48 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
...
We would also need to spell out in detail exactly how all this works
in
DO, DO*, and friends. It's obvious what should happen if you think
in
terms of the expansion into a LET or LET* form, but we don't want to
leave that up to the readers to figure out.
Actually, I think that we ought to provide example macro definitions for
almost all of the macros in CLtL in order to avoid the ambiguity in
their descriptions. For example, as I think Moon or Weinreb pointed
out, CLtL doesn't specify the result of this program:
(setq foo nil)
(dotimes (i 10)
(push #'(lambda (n) n) foo))
(mapcar #'funcall foo)
At the very least, it should be specified for DO, DOLIST and DOTIMES
whether they repeatedly rebind their variables or simply SETQ them. I
don't imagine that any implementation does rebinding for DO, but it's
just as simple as SETQ for DOLIST.
I disagree with Pavel's proposal for LAMBDA (and, therefore, DEFUN).
He
suggests that the scope of all the declarations should coincide with
the
scope of the first required parameter -- in effect, this follows the
current rule of making the declarations wrap everything. That seems
wrong to me. The variables are bound and the init-forms are computed
left-to-right, as in LET*. If we change LET* in the way Pavel
suggests,
we ought to change LAMBDA in the corresponding way: the scope of a
declaration matches the scope of the variable binding it applies to;
the
scope of declarations that do not apply to variable-bindings created
by
the lambda list includes only the body of the form.
-- Scott
I considered that approach in writing up my proposal and actually like
it better than the ``whole form'' notion given there. The only problem
I saw (and still see) with it is that in cases like this:
(defun bar (&optional (x (foo)))
(declare (inline foo))
...)
the call to FOO in the init-form is not covered by the INLINE
declaration. Further, the only way to affect it at all is to use
LOCALLY. I wasn't sure if this was an important enough problem to force
a change, so I put in the current semantics and waited to see. Now that
you've pointed it out, I'm in agreement with you; the consistency with
LET* is much more important than any obscure difficulty in init-forms.
Pavel
∂13-Jul-86 1404 Masinter.pa@Xerox.COM Re: functionp
Received: from XEROX.COM by SU-AI.ARPA with TCP; 13 Jul 86 14:04:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 86 13:56:36 PDT
Date: 13 Jul 86 13:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: functionp
In-reply-to: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>'s
message of Fri, 11 Jul 86 10:19 EDT
To: common-lisp@SU-AI.ARPA
Message-ID: <860713-135636-1518@Xerox>
DLW: "If in some implementation (functionp 3) returned T, I would not
call that legitimate."
I was using the word "legitimate" to mean "complying with what the book
says", rather than in the sense of following good software design
principles.
I've known Lisp systems which overlayed some range of fixnums with
"binary program space" (Lisp/360 did this, as did Interlisp-10) where
the address of some system functions were indistinguishable from the
address of the integer 3. In such a system, (FUNCTIONP 3) might well be
true, since (symbol-function 'CAR) could return 3. FUNCALLing such a
thing would just start executing that address.
This isn't a great design, and I don't want to defend it, but my point
is that there's nothing in the book to prevent it; there's no
requirement on the FUNCTION type other than that it is true of symbols,
lists that begin with LAMBDA, and of whatever FUNCTION and COMPILE might
return.
I suppose FUNCIONP requires a "clarification", but I'm not sure what the
clarification would say. Here are some random ideas on how to clarify or
modify FUNCTIONP. I don't like any of them very much:
a) "the result of FUNCTIONP is implementation-dependent. Users should
not rely on FUNCTIONP returning anything other than T, although
implementations are encouraged to make the check as specific as
possible. FUNCTIONP is intended for user-interface situations where a
program wants to check as soon as possible whether or not something is a
valid function."
b) change the language to *require* that compiled function objects be a
distinct data type. Define FUNCTIONP to be
(defun functionp (x) (or (symbolp x) (consp x) (compiled-function-p x)))
b') same, but change (consp x) to be (and (consp x) (eq (car x)
'lambda))
c) make a list of types that FUNCTIONP *has* to be disjoint from
(NUMBER, things defined with DEFSTRUCT) but specificly warn that whether
or not other types (VECTOR?) are allowed to intersect with things that
are FUNCTIONP.
∂13-Jul-86 1510 FAHLMAN@C.CS.CMU.EDU functionp
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 15:09:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 13 Jul 86 18:10:18-EDT
Date: Sun, 13 Jul 1986 18:10 EDT
Message-ID: <FAHLMAN.12222444020.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Subject: functionp
In-reply-to: Msg of 13 Jul 1986 16:56-EDT from Masinter.pa at Xerox.COM
We clearly need to develop a proposal on how to fix up the Function
data-type. Probably Function is the union of Function-Name and
Function-Object, where the things that qualify for each of these
sub-classes are carefully enumerated. Certainly a concept like
Compiled-Function has to be defined as something (we don't need to
specify what) that the compiler produces and that we can test for. We
need to replace the old wording about "suitable for use by APPLY" or
whatever, and the correctness and well-formedness of the function should
play no part in the type decision.
If anyone wants to try to produce a comprehensive proposal on this, feel
free: if not, I'll get to it sometime soon.
-- Scott
∂13-Jul-86 1608 FAHLMAN@C.CS.CMU.EDU Decisions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 16:08:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 13 Jul 86 19:09:09-EDT
Date: Sun, 13 Jul 1986 19:09 EDT
Message-ID: <FAHLMAN.12222454734.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Decisions
I believe that we are ready to start making formal decisions on what
should go into the new language definition that we will later propose to
the standards organizations.
The current plan is this:
I am maintaining three online files: a list of issues, culled from old
mail, that need to be resolved (not yet completed), a list of proposals
that are before the technical committee, and a list of decisions that
have been made by the technical committee. Issues will be raised and
discussed on the Common Lisp mailing list, a few at a time (I hope!).
Whenever I think the discussion has converged, as much as it is going to
converge, I will send out a formal proposal on the issue, or a set of
proposals representing the live alternatives. People will have an
opportunity for a last round of comments on the proposals, and then the
technical committee will make a decision. That decision will be
recorded in the decisions file. Such decisions will be final unless the
technical committee decides to re-open them.
As of now, no such decisions have been made. The issues that have been
discussed on the mailing list and tentatively settled since CLtL was
written, including most of the issues on the list Guy distributed in
Bosotn, will be run through the above process for formal approval. I
hope that most such things will be approved quickly, without too much
re-hashing of old arguments. We have a lot of ground to cover.
We are also writing a new language definition document from scratch. It
was too complicated to get the rights to use CLtL or other existing
manuals without a lot of legal strings attached. The new document will
differ in form from CLtL: it will be written as a specification, with
emphasis on precision rather than tutorial value. The intent is that
the language definition contained in this document will be exactly the
language defined in CLtL, as modified by the approved changes. In the
end, however, this document is what we will submit as a standard, and
it will become the definitive text in the event of any discrepancy.
There may also be a second edition of CLtL, updated by Guy Steele to
match the new spec. This manual will aimed at meeting the needs of the
working programmer, and it will explicitly point to the language
definition document as the definitive specification of Common Lisp.
I have encouraged Guy to produce such a thing, since I think this
document will serve a useful purpose alongside the official definition,
but this is not one of the things our committee has anything to do with.
All of the files mentioned above, plus the evolving drafts of the
language definition document, will be kept online on C.CS.CMU.EDU, a
Dec-20 system, in directory PRVA:<SLISP.STANDARD>. These files can be
FTP'ed to other arpanet sites with anonymous login. To find your way
around, first read the READ-ME.TXT file. There is not much of interest
in this directory now, except for the ISSUES.TXT file, which is still
incomplete, but people are welcome to browse. I will send mail to this
list when parts of the specificaiton document are ready for review and
discussion, but that will not happen for a couple of months, at least.
At the moment, there is no mechanism for distributing this stuff to
sites that are unable to FTP it. I am hoping that ISI will soon be in a
position to handle such distribution.
The first few proposals will be sent out later this evening.
-- Scott
∂13-Jul-86 1750 FAHLMAN@C.CS.CMU.EDU Decisions and Discussions
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 17:49:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 13 Jul 86 20:50:14-EDT
Date: Sun, 13 Jul 1986 20:50 EDT
Message-ID: <FAHLMAN.12222473134.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Decisions and Discussions
One additional point: If people do peek at the ISSUES.TXT file and see
something that looks wrong, or if you want to add some topics, it would
be helpful if you would contact me directly by netmail and do not send a
message to Common-Lisp. I'm afraid that such messages will start
discussions of their own, and that we'll end up with too many
discussions going on at once.
If these discussions do get started, I'll ask people to suspend some of
the topics while we work on others. As long as something is on the
ISSUES list, it won't be forgotten.
There are still many things that need to be added to the ISSUES list,
including Guy's list of changes and things that were discussed shortly
after the Boston meeting. I'll tell people when I think the list is
complete, and THEN it would be appropriate to tell me about things that
I missed.
Thanks,
Scott
∂13-Jul-86 1802 FAHLMAN@C.CS.CMU.EDU Proposal #1
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 18:02:50 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 13 Jul 86 21:03:16-EDT
Date: Sun, 13 Jul 1986 21:03 EDT
Message-ID: <FAHLMAN.12222475508.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: Proposal #1
Last call for comments on the following, before the technical committee
tries to make a decision on it. I am in favor of this proposal. Most
of the comments have been favorable, except for some technical problems
raised by Loosemore (I don't know if she is now satisfied) and some
doubts expressed by Masinter. A few people favored doing this with
TYPE-OF, but I think that option has been pretty well shot down in
subsequent discussion.
One change from what was discussed earlier is that the exemption from
error signalling now would apply for SAFETY = 0 or 1, not just SAFETY =
0. This gives implementors the option of turning on some of the less
expensive checks at Safety = 1, and the rest of them at SAFETY > 1.
This flexibility may be useful in some systems.
---------------------------------------------------------------------------
Proposal #1: Error signalling
This is a proposed change, upward compatible from the user's
point of view:
Create three levels of errors: Class 1 errors must be deteced and
signalled by any legal implementation. Class 2 errors must normally be
detected and signalled, but implementations may choose to omit the error
testing and signalling in code compiled with an OPTIMIZE SAFETY value of
0 or 1; in this case, the behavior if the error occurs is unpredictable,
and perhaps fatal to the Lisp. Class 3 errors are considered to be
errors, but it is left to the discretion of the implementor whether and
under what conditions Class 3 errors are detected and signalled.
There will be a usage note indicating that portable code should not
depend for correct operation on Class 2 errors being signalled, since
under some conditions of compilation they will not be.
Note: CLtL has classes corresponding to Class 1 ("signals an error") and
Class 3 ("is an error"). We intend to propose that certain errors,
including wrong number of arguments to a function, array references out
of bounds, and certain wrong-type errors, be moved from Class 3 to Class
2. However, such proposals will be discussed individually, after an
error system has been adopted. The decision at this point is whether we
should use the three-level error system as the working assumption in
future discussions.
∂13-Jul-86 1815 FAHLMAN@C.CS.CMU.EDU Proposals 2, 3, & 4
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 18:15:26 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 13 Jul 86 21:15:48-EDT
Date: Sun, 13 Jul 1986 21:15 EDT
Message-ID: <FAHLMAN.12222477788.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposals 2, 3, & 4
Last call for comments on these. They're all related, so I'll put all
three in the smae message. I favor 2, 3A, and 4, though I really don't
care much whether 3A or 3B is chosen. Most of the discussion centered
around the exact format of these functions, whether a fast version as in
3A is needed, and whether we should do all of this with TYPE-OF instead.
I think that the TYPE-OF idea hs been effectively shot down in later
discussion.
There has been little discussion of issue 4, the semi-standard interface
for getting the parameter names, but I think that this is potentially
quite useful and costs very little to adopt, since implmentors are free
to make it a no-op.
---------------------------------------------------------------------------
Proposal #2: Argument List Information
Proposed Extension:
(FUNCTION-PARAMETERS <function>)
Takes one argument which must be a function, not a macro or special
form.
Returns the following six values:
1. Number of required parameters in the function's lambda list.
2. Number of optional parameters in the function's lambda list.
3. T if the function's lambda list contains the &REST lambda-keyword;
NIL otherwise.
4. T if the function's lambda list contains the &KEY lambda-keyword;
NIL otherwise.
5. A list of all keywords accepted by the function, in arbitrary order.
This list may be pre-stored, so it should not be destructively
modified by the user.
6. T if the function's lambda list contains the &ALLOW-OTHER-KEYS
lambda-keyword; NIL otherwise.
If return value 4 is NIL, 5 and 6 must also be NIL.
---------------------------------------------------------------------------
Proposal #3: Argument List Information
Two alternatives to choose from:
#3A:
Proposed extension:
FUNCTION-PARAMETER-RANGE (function)
The argument must be a function, not a macro or special form. Returns
two values, the minimum legal number of arguments and the maximum legal
number of arguments. If the function's argument list contains &rest or
&key, the second return value is NIL, meaning that there is no maximum
number of arguments.
- OR -
#3B:
Modification to proposal #2:
Add an implementation note to FUNCTION-PARAMETER recommending that
implementations detect calls that will not use the 5th value, and that
they compile such calls in a way that will not cons up a keyword list.
---------------------------------------------------------------------------
Proposal #4: Argument Name Information
Proposed extension:
(FUNCTION-PARAMETER-NAMES <function>)
Takes one argument which must be a function, not a macro or special
form.
This function returns the names of the parameters to a function, as
specified in the argument list, if such information is available. An
implementation may choose to provide this information for all functions,
only for some, or for none. The final return value specifies whether
the information is in fact available. If this is NIL, the other return
values will also be NIL.
Returns four values:
1. A list containing the symbols naming the required parameters, in order.
2. A list containing the symbols naming the optional parameters, in order.
3. A symbol naming the rest parameter, if any.
4. T if the information returned by this function is valid; NIL otherwise.
Note: This function is included primarily for the convenience of users and to
provide a uniform interface for portable debugging tools.
∂13-Jul-86 1818 FAHLMAN@C.CS.CMU.EDU Oops
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 18:18:02 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 13 Jul 86 21:18:24-EDT
Date: Sun, 13 Jul 1986 21:18 EDT
Message-ID: <FAHLMAN.12222478262.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Oops
Please ignore the sentence about TYPE-OF in the preamble to Proposal #1.
That slipped in from the other proposal before I split them into two
messages.
-- Scott
∂13-Jul-86 1953 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #1
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 13 Jul 86 19:53:38 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 40498; Sun 13-Jul-86 22:54:34 EDT
Date: Sun, 13 Jul 86 22:53 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #1
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12222475508.BABYL@C.CS.CMU.EDU>
Message-ID: <860713225300.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
I am in agreement that "is an error" and "signals an error" don't
express enough variety and that more classes are needed in order to help
us toward the goals mentioned on pages 1-3, with the addition of
Robustness. [I don't really want to start a side discussion, but I
think one of the goals >should be< that the language is Robust, meaning
that it encourages the user to write correct code, both because of the
definition and by run time checking. This isn't really mentioned on
pages 1-3, even under the goals of Expressiveness or Power.]
The following is a little off-the-wall, and can be ignored if nobody
else sees any worth in it. There are some more substantive questions in
the last paragraph that shouldn't be lightly ignored. I'm wondering if
the three levels is enough. Given that there are four values of SAFETY,
one could imagine five classes. Assign the five classes a "severity"
number ranging from 0 to 4 (inclusive). A class arranges for the error
to be signalled if its number is <= the setting of the safety switch.
Therefore, Severity 0 errors ("Signals an error") always signals an
error because 0 <= all safety settings. Severity 4 ("is an error")
doesn't necessarily generate code, because all 4 is not <= any settings
of safety. The third class you are proposing (that fits between), would
be Severity 2, since 2 <= 2,3. [I don't really like the word "severity"
because intuition says that higher severity implies a higher number.]
This gives us a set of finer knobs, but on the other hand makes it
harder for the language designers to assign a severity to each of the
many possible cases.
The not-so-light issue which I don't remember the answer to: Does safety
affect the caller or the callee, or both, and what burden does this put
on the implementor. For example, if I write:
(defun safe-slow-2d-aref (array sub1 sub2)
(declare (optimize (speed 0) (space 3) (safety 3))
(notinline aref))
(aref array sub1 sub2))
(defun unsafe-fast-2d-aref (array sub1 sub2)
(declare (optimize (speed 3) (space 3) (safety 0))
(notinline aref))
(aref array sub1 sub2))
What does this imply about the AREF function? Is the implementor bound
to implement a variety of functions that may be called by programs
compiled with different switch settings, or is there one AREF function
that always checks the number of arguments, always does bounds checking,
etc? [I think this is more an issue for the builtin "subprimitives"
than the more complex (e.g., FIND, REMOVE-IF-NOT, etc) functions, but
the latter may need to be addressed too.]
∂13-Jul-86 2034 FAHLMAN@C.CS.CMU.EDU Proposal #1
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 20:34:07 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 13 Jul 86 23:33:53-EDT
Date: Sun, 13 Jul 1986 23:33 EDT
Message-ID: <FAHLMAN.12222502920.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Proposal #1
In-reply-to: Msg of 13 Jul 1986 22:53-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
I don't think that your severity proposal can possibly fly. The
decision about whether to signal an error is a function of two things:
the severity of the effects of the error and the cost of detecting it.
The cost of detecting various kinds of errors varies tremendously from
one implementation to another (and the danger posed by non-detection can
vary as well) so we can't really create a scalar ranking of errors and
standardize it across all implementations. This is a multi-dimensional
problem.
I thought we had discussed your second point at some length, when Sandra
Loosemore expressed dismay at having to provide two versions of all
built-in functions, but I'll try again using your AREF example.
If we adopt proposal #1 and then decide that aref-out-of-bounds is a
Class 2 error, your SAFE-SLOW-2D-AREF must check for and signal
such errors. So there must be a built-in AREF function that does this
checking. I would be surprised to learn of an implementaiton that does
not already provide this function.
Under the same assumptions, your UNSAFE-FAST-2D-AREF would be allowed to
call the same built-in function, or the implementors could choose to
provide a second, quick and dirty AREF function that would be called
instead.
I doubt that many implementations will bother to provide this second
version of AREF. People interested in speed will allow the system to
compile their AREF calls inline, and that's where omitting the check can
buy you some speed. In general, most of the potential Class 2 errors
are things that really ought to be checked for, but where the
error-checking can be too burdensome if the call is open-coded.
The main burden to implementors will be to put optional error-checking
code into various inline code expansions. Most implementations already
compile in checks if the user asks for safety, but not all do.
-- Scott
∂13-Jul-86 2120 RAM@C.CS.CMU.EDU Proposals 2, 3, & 4
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 21:20:48 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sun 13 Jul 86 23:59:34-EDT
Date: Sun, 13 Jul 1986 23:58 EDT
Message-ID: <RAM.12222507501.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposals 2, 3, & 4
I am not very happy with proposal #4, FUNCTION-PARAMETER-NAMES. I
have three main objections:
1] There is no way to obtain the names of keyword arguments.
2] There is no way to determine defmacro syntax. The arguments to
the macro function are always the form and environment, which
isn't very useful.
3] Returning the names as symbols has efficiency implications.
Spice Lisp stores argument lists as strings to save space. Since
the actual symbols naming the argument aren't stored, it would be
difficult to return the names as symbols.
I question that there is any legitimate portable use of the function
other than simply obtaining the information so that it can be printed
to the user. It seems that it would be simpler and less restrictive
to have a function DESCRIBE-ARGUMENTS which takes a function and a
stream and prints useful information about how that function may be
used.
Rob
∂13-Jul-86 2129 Masinter.pa@Xerox.COM Re: Proposal #1
Received: from XEROX.COM by SU-AI.ARPA with TCP; 13 Jul 86 21:29:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 86 20:56:08 PDT
Date: 13 Jul 86 20:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Proposal #1
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
13 Jul 86 21:03 EDT
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860713-205608-1644@Xerox>
The expressions of doubt that Scott alluded to in his message is
summarized as follows. There are two situations: before there is an
error system that defines what "signals an error" means, and after. In
one, the distinction between class #2 and class #3 is moot. In the
other, the distinction violates an important principle of Common Lisp
declarations, namely, that they do not affect the results of correct
programs.
Until there is a standard for what "signals an error" means,
1) There is no semantic difference between "signals an error"
and "is an error" other than the general exhortation to
implementors to try to signal all "is an error" situations.
2) Implementors are already encouraged to signal errors
in all "is an error" situation, and, presumably, SAFETY
declarations might well have some effect on it.
In this situation, the distinction between class #2 and class #3 errors
is moot.
After there is an error system which defines what "signals an error"
means,
1) "signals an error" has program language semantics, and
2) "correct" programs can rely on "signals an error" to
catch the error and process it in some standard way, and
3) declarations about safety shouldn't affect the operation
of correct programs.
In this situation, any error in class #2 would violate principle (3).
∂13-Jul-86 2148 Masinter.pa@Xerox.COM Proposal #1 - minor revision
Received: from XEROX.COM by SU-AI.ARPA with TCP; 13 Jul 86 21:48:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 86 21:48:49 PDT
Date: 13 Jul 86 21:48 PDT
From: Masinter.pa@Xerox.COM
Subject: Proposal #1 - minor revision
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860713-214849-1667@Xerox>
There was an error in my message -- I deleted the wrong sentence in Case
1. Here's what I meant to say:
- - - - - - - - - - - -
The expressions of doubt that Scott alluded to in his message is
summarized as follows. There are two situations: before there is an
error system that defines what "signals an error" means, and after. In
one, the distinction between class #2 and class #3 is moot. In the
other, the distinction violates an important principle of Common Lisp
declarations, namely, that they do not affect the results of correct
programs.
Until there is a standard for what "signals an error" means,
1) There is no semantic difference between "signals an error"
and "is an error" other than the vague statement that
"signals an error" will somehow "enter the debugger".
However, no correct program can depend upon any
condition signalling an error since the action of the
debugger is undefined.
2) Implementors are already encouraged to signal errors
in all "is an error" situation, and, presumably, SAFETY
declarations might well have some effect on it.
In this situation, the distinction between class #2 and class #3 errors
is moot.
After there is an error system which defines what "signals an error"
means,
1) "signals an error" has program language semantics, and
2) "correct" programs can rely on "signals an error" to
catch the error and process it in some standard way, and
3) declarations about safety shouldn't affect the operation
of correct programs.
In this situation, any error in class #2 would violate principle (3).
∂13-Jul-86 2204 FAHLMAN@C.CS.CMU.EDU Proposals 2, 3, & 4
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 22:04:25 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 14 Jul 86 01:04:45-EDT
Date: Mon, 14 Jul 1986 01:04 EDT
Message-ID: <FAHLMAN.12222519453.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Proposals 2, 3, & 4
In addition to printing out the argument list for users, I had in mind
things like trace functions and debuggers that might want to print
ITEM: FOO
LIST: (BAR BAH BURP)
rather than
Argument 1: FOO
Argument 2: (BAR BAH BURP)
One might argue that all such applications are implementation-dependent
anyway, and one might be right about that. Anyway, that's what I had in
mind in proposing this function in this particular form.
Regarding Rob's specific objections:
1] There is no way to obtain the names of keyword arguments.
These aren't interesting. We can get at the keywords themselves via
FUNCTION-PARAMETERS.
2] There is no way to determine defmacro syntax...
The situation with DEFMACRO is very complicated. The "lambda list" to
DEFMACRO only gives part of the story, since some things are evaluated,
others not, and others are used in even more complex ways. I grant that
in many cases it is useful to look at the "lambda list" of the DEFMACRO
3] Returning the names as symbols has efficiency implications.
Spice Lisp stores argument lists as strings to save space.
The symbols could be extracted from a stored string fairly easily,
modulo package problems. Then again, package problems could be serious
here: we might not want to call this function if it would create a lot
of symbols that would not otherwise exist at runtime. Perhaps it would
be better to return a list of strings, each of which names one of the
arguments.
-- Scott
∂13-Jul-86 2211 STANKULI%cs.umass.edu@CSNET-RELAY.ARPA Golden Hill Common Lisp installation on DEC Rainbow
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Jul 86 22:11:25 PDT
Received: from umass-cs by csnet-relay.csnet id an09342; 14 Jul 86 1:13 EDT
Date: Sun, 13 Jul 86 21:44 EST
From: STANKULI%cs.umass.edu@CSNET-RELAY.ARPA
To: common-lisp@SU-AI.ARPA
Subject: Golden Hill Common Lisp installation on DEC Rainbow
(* this message was sent to info-dec-micro and no one there has replied
with the Golden Hill - DEC Rainbow parameters for the GMACS key binding
parameters. thought i would try here, but DEC-specific information is
probably want i need. LISP implementors intended for microcomputers
might read the last paragraph. *)
i recently got Golden Hill's Common LISP running on my Rainbow 100A and i
thought i would make some comments and a plea for help.
the memory upgrade to 832K on my two Rainbows went alright. one of the
memory boards i received was defective, but a call to the Atlanta DEC hot line
produced a DEC repairman who replaced the defective board within a week.
the software installation was pretty poor however. it took about 4+ hours to
do the hard disk installation. following the instructions in the manual just
did not work. some of the points in the 'known bugs' addendum took care of
some of the problems, but the installation of the San Marco Explorer had to be
done by hand. that was drag.
i want to bind the GMACS editor functions to the Rainbow personal function
keys and numeric keypad. GMACS has most of the editting functions i usually
have in other word processing environments, but key binding does not seem
covered in the installation manual. i called Golden Hill first and their tech
people showed me the GCLISP\GMACS\EDCOMTAB.LSP which has the key definition
functions as follows:
(DEF-KEY
#X080 ; key hexidecimal parameter (HELP key)
*GMACS-HELP-COMMAND-TREE*) ; GMACS editor function
the Golden Hill technical support could not give me the hex specifications
for the function keys or the keypad. they said that they developed the IBM
version and that someone in DEC did the Rainbow specific modifications. the
guy i talked with said that DEC would not give them the technical
specifications of the Rainbow sufficient for them to do the work. he said i
had to talk with DEC about the key bindings.
then i called Atlanta DEC again. this time i hit a brick wall. they never
heard of Common LISP and said i had to buy software support before they would
search any answers. when i found a problem in the hardware installation, they
fixed it no problem, but apparently the same support of software is not given.
they suggested i call Golden Hill-- full circle: no answers.
i looked through PC100 Technical Specifications and found that the key
hexidecimal specs were different from the few i could find in EDCOMTAB.LSP.
but they were consistently distanced so i applied a conversion. unfortunately,
the resultant file did not bind the keys. both DEC and Golden Hill said to ask
around and find a hacker who has already bound keys and ask for help. anybody
out there done this? its the pits that two professional technical support
teams say to find a hacker and ask for help.
another major bogus with the Golden Hill Common LISP is the use of keycard
floppy disks and copy protection on their diskettes. the copy protection is
why software installation took all afternoon. the keycard means that one of
their original floppies has to be in drive A before Common LISP will install
from the hard disk. when a floppy wears out, they expect a $30 replacement
charge for what is a disservice to the user. i plan to break the copy and
remove that keycard crap as soon as possible so the Common LISP i bought will
operate as a computer utility on my machine rather than as a property interest
of the publisher. when will software publishers learn (like Borland did) that
their interests are protected through reasonable price, efficient operation,
user support and revision services?
stan
[EOF]GCLISP.Mai≠
∂14-Jul-86 0723 shebs%utah-orion@utah-cs.arpa Re: Proposals 2, 3, & 4
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 07:23:10 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA10504; Mon, 14 Jul 86 08:23:09 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA10135; Mon, 14 Jul 86 08:23:04 MDT
Date: Mon, 14 Jul 86 08:23:04 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8607141423.AA10135@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: Proposals 2, 3, & 4
Summary:
Expires:
References: <RAM.12222507501.BABYL@C.CS.CMU.EDU>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <RAM.12222507501.BABYL@C.CS.CMU.EDU> RAM@C.CS.CMU.EDU (Rob MacLachlan) writes:
>It seems that it would be simpler and less restrictive
>to have a function DESCRIBE-ARGUMENTS which takes a function and a
>stream and prints useful information about how that function may be
>used.
> Rob
I agree. Something like FUNCTION-PARAMETER-NAMES is likely to get
used only for something like DESCRIBE-ARGUMENTS anyway, since a debugger
is going to need a lot more help, for beating on stacks directly etc.
Actually DESCRIBE-ARGUMENTS should maybe be subsumed by DESCRIBE, and
the standard should give a lot more hints about what sort of useful
things DESCRIBE might do.
stan
∂14-Jul-86 0756 LOOSEMORE@UTAH-20.ARPA proposal #1
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 07:56:20 PDT
Date: Mon 14 Jul 86 08:54:31-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: proposal #1
To: common-lisp@SU-AI.ARPA
cc: fahlman@C.CS.CMU.EDU
Message-ID: <12222626842.16.LOOSEMORE@UTAH-20.ARPA>
As long as the list of functions whose error-checking behavior relies on
the safety switch is kept small, I can live with this proposal. I'm still
against having to provide multiple definitions of functions, but if only
a dozen or two functions that are normally compiled inline anyway are
affected, most of the nastier issues are bypassed. (Perhaps if somebody
could put together a list of these functions, it would give the rest of us
more information as a basis for making a decision?)
However, I agree with Masinter's remarks that saying something "is an error"
in some contexts and "signals an error" in others is bogus. The situations
in question should remain "an error", whether or not the error is signalled.
I tend to think of this as a means of providing a more user-friendly error
message -- in PSL/PCLS, for example, nearly all of the "is an error"
situations end up signalling *some* error eventually, but it takes some
detective work to figure out that the reason why you got an access violation
is because you tried to do (CDR -3) from compiled code!
Incidentally, currently implementations are free to ignore any declarations
they don't feel like processing (p 161), so presumably if we tie signalling
of errors to the optimize safety declaration, those implementations that
choose to ignore this declaration will not be bound to signal these errors
at all. This seems like another reason to make the signalling of errors
in these situations something that is strongly encouraged rather than an
absolute requirement.
-Sandra
-------
∂14-Jul-86 0843 FAHLMAN@C.CS.CMU.EDU proposal #1
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Jul 86 08:43:06 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 14 Jul 86 11:43:27-EDT
Date: Mon, 14 Jul 1986 11:43 EDT
Message-ID: <FAHLMAN.12222635704.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: proposal #1
In-reply-to: Msg of 14 Jul 1986 10:54-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
For the Nth and hopefully last time, I guarantee you that you will not
ever have to provide multiple versions of ANY built-in function in order
to comply with proposal #1. You will have to provide exactly one
version of each function, and that version will do full error checking
for whatever we decide is a class 2 error. Please do not even consider
providing quick-and-dirty versions as well. Very few implementations
will do this, since the speed gain will be neglegible in most cases.
Similarly, implementations will still be free to ignore any declarations
they want to. If they ignore the OPTIMIZE declaration, they will be
required to signal all the class 2 errors. If they want to cut corners
on this signalling requirement for speed or code compactness, then they
will have to consult the OPTIMIZE declarations to see if this is OK.
-- Scott
∂14-Jul-86 0925 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #1
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 09:20:52 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 19246; Mon 14-Jul-86 12:18:43 EDT
Date: Mon, 14 Jul 86 12:19 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #1
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12222502920.BABYL@C.CS.CMU.EDU>
Message-ID: <860714121921.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sun, 13 Jul 1986 23:33 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I don't think that your severity proposal can possibly fly.
One of us is confused. I see Proposal#1 being to expand 2 classes of
errors to 3. I see my extension doing the same thing but expanding to 5
classes instead of 3. We should probably just drop it.
The
decision about whether to signal an error is a function of two things:
the severity of the effects of the error and the cost of detecting it.
The cost of detecting various kinds of errors varies tremendously from
one implementation to another (and the danger posed by non-detection can
vary as well) so we can't really create a scalar ranking of errors and
standardize it across all implementations. This is a multi-dimensional
problem.
I thought we had discussed your second point at some length, when Sandra
Loosemore expressed dismay at having to provide two versions of all
built-in functions, but I'll try again using your AREF example.
...
OK. Sorry if this was already explained as explicitly as you did in
some previous mail.
∂14-Jul-86 1021 Marilyn←Hodgetts.ROCH@Xerox.COM DL
Received: from XEROX.COM by SU-AI.ARPA with TCP; 14 Jul 86 10:19:23 PDT
Received: from Concord.ms by ArpaGateway.ms ; 14 JUL 86 10:18:46 PDT
Sender: "Marilyn←Hodgetts.ROCH"@Xerox.COM
Date: 14 Jul 86 10:13:46 PDT (Monday)
Subject: DL
From: "Marilyn←Hodgetts.ROCH"@Xerox.COM
To: common-lisp@SU-AI.Arpa
Message-ID: <860714-101846-1968@Xerox>
Please remove me from your mailing list. Thank you.
Marilyn Hodgetts:Roch:Xerox
∂14-Jul-86 1100 LOOSEMORE@UTAH-20.ARPA proposal #1 again
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 10:29:28 PDT
Date: Mon 14 Jul 86 11:26:33-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: proposal #1 again
To: fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Message-ID: <12222654520.9.LOOSEMORE@UTAH-20.ARPA>
From: Fahlman@C.CS.CMU.EDU (Scott E. Fahlman)
Date: 14 Jul 86 15:43:00 GMT
Similarly, implementations will still be free to ignore any declarations
they want to. If they ignore the OPTIMIZE declaration, they will be
required to signal all the class 2 errors. If they want to cut corners
on this signalling requirement for speed or code compactness, then they
will have to consult the OPTIMIZE declarations to see if this is OK.
Wouldn't it be more consistent to make the default behavior in the absence
of optimize declarations *not* to require that the errors be signalled?
The proposal is that the errors don't need to be signalled if the optimize
safety setting is 0 or 1, and according to CLtL, the "usual" value of this
parameter is 1.
-Sandra
-------
∂14-Jul-86 1100 DLW@QUABBIN.SCRC.Symbolics.COM Proposal #1 - minor revision
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 10:31:31 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 19290; Mon 14-Jul-86 13:29:41 EDT
Date: Mon, 14 Jul 86 13:31 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #1 - minor revision
To: Masinter.pa@XEROX.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860713-214849-1667@Xerox>
Message-ID: <860714133103.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 13 Jul 86 21:48 PDT
From: Masinter.pa@Xerox.COM
3) declarations about safety shouldn't affect the operation
of correct programs.
In this situation, any error in class #2 would violate principle (3).
That's a very intersting point. I believe that that answer is that
principle (3) should really read as follows:
3) If there are two correct Common Lisp programs, that are identical to
each other except for the presence or absence of safety declarations,
then they should behave identically.
In the case of class #2 errors, there are programs which are valid
Common Lisp programs when safety is declared to be 2 or more, but which
are not valid Common Lisp programs otherwise. Under this
interpretation, principle (3) is not violated. The presence or absence
of the declaration is what makes the program valid.
∂14-Jul-86 1159 bradley@ATHENA.MIT.EDU please take me off
Received: from ATHENA.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 11:59:13 PDT
Received: by ATHENA (5.45/4.7)
id AA21344; Mon, 14 Jul 86 14:56:56 EDT
Received: by HERA (5.45/4.7)
id AA15195; Mon, 14 Jul 86 14:56:56 EDT
Message-Id: <8607141856.AA15195@HERA>
To: common-lisp@su-ai.arpa
Subject: please take me off
Date: Mon, 14 Jul 86 14:56:53 -0500
From: bradley@ATHENA.MIT.EDU
The rate at which mail arrives on this list is far greater than
I can manage reasonably; please take me off the list.
-Steve
∂14-Jul-86 1257 @MCC.COM:krall%pp@mcc.arpa Re: Proposals 2, 3, & 4
Received: from MCC.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 12:54:32 PDT
Received: from pp.mcc.com by MCC.COM with TCP; Mon 14 Jul 86 14:41:26-CDT
Posted-Date: Monday, 14 July 1986, 14:46-CDT
Message-Id: <8607141944.AA03543@pp.mcc.com>
Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA6710)
id AA03543; Mon, 14 Jul 86 14:44:02 cdt
Date: Monday, 14 July 1986, 14:46-CDT
From: <krall@pp.mcc.com (Ed Krall)>
Sender: KRALL%pp@mcc.arpa
Subject: Re: Proposals 2, 3, & 4
To: franz!fizzy!jkf@kim.berkeley.edu
Cc: common-lisp@su-ai.arpa
In-Reply-To: <8607141714.AA09863@fizzy>
As regards:
(a b c &optional d e &rest r &key x y &allow-other-keys)
This is not unlike the problem of getting the command line
information into an application program. There are two options:
1. pass it unedited to the application program, or
2. do some primitive parsing on it, then pass it to the program.
#2 saves work for the user, but may lose information. #1 may be
a pain, but should always work (even in a semi-portable
fashion).
I like your proposal. Some might object that the symbol names
may be not carried around at run-time, so you could encode it
(1 2 3 &optional 4 5 &rest 6 &key 7 8 &allow-other-keys)
or even (shudder!) as the following signature
"010203&O0405&R060&K0708&A"
-Ed Krall
Microelectronics and Computer Technology Corporation
9430 Research Blvd.
Austin, Texas 78759
(512) 834-3406
ARPA: krall@mcc.arpa
UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall
∂14-Jul-86 1113 franz!fizzy!jkf@kim.Berkeley.EDU Re: Proposals 2, 3, & 4
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 14 Jul 86 10:59:25 PDT
Received: by kim.Berkeley.EDU (5.53/1.14)
id AA01769; Mon, 14 Jul 86 11:00:13 PDT
From: franz!fizzy!jkf@kim.berkeley.edu
Received: from fizzy by franz (5.5/3.14)
id AA01701; Mon, 14 Jul 86 10:15:06 PDT
Received: by fizzy (4.12/3.14)
id AA09863; Mon, 14 Jul 86 10:14:38 pdt
Return-Path: <fizzy!jkf>
Message-Id: <8607141714.AA09863@fizzy>
To: "Scott E. Fahlman" <ucbkim!C.CS.CMU.EDU!Fahlman>
Cc: common-lisp@su-ai.arpa
Subject: Re: Proposals 2, 3, & 4
In-Reply-To: Your message of Sun, 13 Jul 86 21:15:00 EDT.
<FAHLMAN.12222477788.BABYL@C.CS.CMU.EDU>
Date: Mon, 14 Jul 86 10:14:36 PDT
We would be better off defining a primitive function which returns
the argument list information in a 'raw' form and then define the
various higher level functions such as function-parameters,
function-parameter-range, function-parameter-names in terms of this
primitive. These functions would be written in Lisp in the
specification document (making them unambiguous and making it easy for
user to modify them if he wants different information back).
The primitive function would return a sequence something like this
(a b c &optional d e &rest r &key x y &allow-other-keys)
or a keyword signifying that it doesn't have the information. The
various items in the sequence would be symbols, using strings loses
package information.
The various higher-level functions would probably want to cache their
information to make repeated querys on the same function faster.
- john foderaro
Franz Inc.
∂14-Jul-86 1124 FAHLMAN@C.CS.CMU.EDU Proposals 2, 3, & 4
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Jul 86 11:19:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 14 Jul 86 14:18:53-EDT
Date: Mon, 14 Jul 1986 14:18 EDT
Message-ID: <FAHLMAN.12222664034.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: franz!fizzy!jkf@KIM.BERKELEY.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: Proposals 2, 3, & 4
In-reply-to: Msg of 14 Jul 1986 13:14-EDT from franz!fizzy!jkf at kim.berkeley.edu
The primitive function would return a sequence something like this
(a b c &optional d e &rest r &key x y &allow-other-keys)
or a keyword signifying that it doesn't have the information.
I don't like this approach at all. It seems to make more work for
everyone and to require that all this information be carried around in
an inefficient and hard-to-parse form.
I am wavering on whether proposal 4 is a good idea in its current form.
Maybe it should be dropped from the standard or replaced with a
semi-standard form that just returns the arglist of a function or macro,
probably as a string. But I think that we want to keep proposal 2 in
its current form as a clean portable way of getting at a function's
external calling conventions.
-- Scott
∂14-Jul-86 1142 FAHLMAN@C.CS.CMU.EDU proposal #1 again
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Jul 86 11:26:38 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 14 Jul 86 14:26:58-EDT
Date: Mon, 14 Jul 1986 14:26 EDT
Message-ID: <FAHLMAN.12222665491.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: proposal #1 again
In-reply-to: Msg of 14 Jul 1986 13:26-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
Wouldn't it be more consistent to make the default behavior in the absence
of optimize declarations *not* to require that the errors be signalled?
The proposal is that the errors don't need to be signalled if the optimize
safety setting is 0 or 1, and according to CLtL, the "usual" value of this
parameter is 1.
The question of what should be required if a system ignores certain
declarations is not the same as what the default should be if the
declarations are not present.
If an implementation doesn't bother to check for optimize declarations,
it should make the conservative assumption and do the error checking.
If this were not the rule, proposal 1 would be meaningless.
You do raise an interesting point, however. Since the default setting
of OPTIMIZE SAFETY is 1 in the absence of any declaration to the
contrary, maybe we should go back to requiring Class 2 errors to be
signalled unless SAFETY = 0. It would be better to require the
signalling unless the user specifically authorizes the system to omit
such tests.
-- Scott
∂14-Jul-86 1342 RWK@YUKON.SCRC.Symbolics.COM Re: GC, exit-to-system
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 13:42:00 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54785; Mon 14-Jul-86 16:40:22 EDT
Date: Mon, 14 Jul 86 16:41 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: GC, exit-to-system
To: franz!fizzy!jkf@kim.berkeley.edu
cc: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
common-lisp@SU-AI.ARPA
In-Reply-To: <8607110525.AA04054@fizzy>
Supersedes: <860714164053.1.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <860714164119.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 10 Jul 86 22:25:30 PDT
From: franz!fizzy!jkf@kim.berkeley.edu
>> From: David Moon
>> ...
>> The concept of calling the GC at a particular
>> time is not meaningful either; the GC runs in parallel with normal
>> computation. I'm sure there are other implementations with different
>> ideas about these concepts. They just don't make very much sense to
>> standardize, because there is so much variation.
I think that you may have missed the point. There are certain
functions performed by many (but perhaps not all) of the
implementations of common lisp. Such functions include stopping
a computation and performing a garbage collection, and exiting to the
operating system. It would be a good thing if the names for these
functions were the same across all common lisps where such
functionality exists.
- john foderaro
Franz Inc.
I think this would just encourage people to write non-portable
code. Calling the GC from a program may make it work better on
one implementation, while making it work not at all, or extremely
poorly, on another.
∂14-Jul-86 1347 RWK@YUKON.SCRC.Symbolics.COM Re: DECLARE SPECIAL Considered Confusing
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 13:46:52 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54795; Mon 14-Jul-86 16:45:23 EDT
Date: Mon, 14 Jul 86 16:46 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: DECLARE SPECIAL Considered Confusing
To: Pavel.pa@Xerox.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860711-184339-1110@Xerox>
Message-ID: <860714164620.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: 11 Jul 86 18:43 PDT
From: Pavel.pa@Xerox.COM
In this message I will give a complete description of my proposal for
declaration scoping. I won't attempt to argue for it on the basis of
``obviousness'' or clarity, though, because I think that there are
people who find each of the two ways of scoping special declarations
confusing. Rather, I like this way of doing things because it satisfies
an important (to me) consistency criterion: the scope of \any/
declaration coincides with a particular lexical identifier scope.
There are six primitive forms in Common Lisp that can both bind
identifiers and carry declarations:
LET LET* FLET LABELS MACROLET LAMBDA
I will describe the scoping rules for declarations in each of these
forms.
You forgot DEFUN and DEFMACRO (and similar top-level definers).
Those, I believe, would be unchanged by your proposal, no?
∂14-Jul-86 1452 Pavel.pa@Xerox.COM Re: DECLARE SPECIAL Considered Confusing
Received: from XEROX.COM by SU-AI.ARPA with TCP; 14 Jul 86 14:52:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 JUL 86 14:51:43 PDT
Date: 14 Jul 86 14:44 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: DECLARE SPECIAL Considered Confusing
In-reply-to: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>'s message of
Mon, 14 Jul 86 16:46 EDT
To: RWK@YUKON.SCRC.Symbolics.COM
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <860714-145143-2412@Xerox>
Date: Mon, 14 Jul 86 16:46 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
You forgot DEFUN and DEFMACRO (and similar top-level definers).
Those, I believe, would be unchanged by your proposal, no?
Those are macros whose behaviour should be understood in terms of the
special forms into which they are defined to expand. It is my opinion
that the language spec should include a complete example macro
definition of all macros so as to make their semantics absolutely clear.
For example, I believe that the basic semantics of DEFUN are as follows:
(defmacro defun (name args &body body decls doc)
`(progn
(setf (symbol-function ,name)
`(lambda ,args ,@decls (block ,name ,@body)))
(setf (documentation ,name 'function)
doc)))
It is thus made clear that the scope of the declarations in DEFUN is
precisely as in an anonymous LAMBDA, just as they should be. It also,
by the way, makes it clear what a non-top-level DEFUN means...
Pavel
PS- Sorry, I used the parse-body feature of &body that hasn't yet been
approved, so shoot me.
∂14-Jul-86 1500 JAR@AI.AI.MIT.EDU DECLARE SPECIAL Considered Confusing
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 14:59:06 PDT
Date: Mon, 14 Jul 86 18:00:13 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: DECLARE SPECIAL Considered Confusing
To: RWK@SCRC-YUKON.ARPA
cc: Common-Lisp@SU-AI.ARPA, Pavel.pa@XEROX.COM,
Moon@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Mon 14 Jul 86 16:46 EDT from Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>
Message-ID: <[AI.AI.MIT.EDU].69829.860714.JAR>
Date: Mon, 14 Jul 86 16:46 EDT
From: Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>
Date: 11 Jul 86 18:43 PDT
From: Pavel.pa@Xerox.COM
There are six primitive forms in Common Lisp that can both bind
identifiers and carry declarations:
LET LET* FLET LABELS MACROLET LAMBDA
I will describe the scoping rules for declarations in each of these
forms.
You forgot DEFUN and DEFMACRO (and similar top-level definers).
Those, I believe, would be unchanged by your proposal, no?
Pavel was only talking about the -primitive- forms. DEFUN and DEFMACRO
are macros. Presumably DEFUN has the obvious expansion in terms of
LAMBDA, so that it follows the same rules as LAMBDA (which I think
should be analogous to LET*, following the easy-to-remember principle
that the scope of a declaration of something bound by an expression is
the same as the scope of the binding itself). DEFMACRO, also
presumably, has a somewhat more complicated expansion, but would also
adhere to the principle.
Technically speaking, the proposal (with this amendment about the
meaning of LAMBDA as per a later message from Pavel, I think) consitutes
a change in the *meaning* of DEFUN and DEFMACRO, although probably not
in its implementation in terms of LAMBDA. In any case DEFUN should be
consistent with LAMBDA.
Jonathan
∂14-Jul-86 1553 franz!fizzy!jkf@kim.Berkeley.EDU Re: GC, exit-to-system
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 14 Jul 86 15:53:44 PDT
Received: by kim.Berkeley.EDU (5.53/1.14)
id AA11856; Mon, 14 Jul 86 15:54:32 PDT
From: franz!fizzy!jkf@kim.berkeley.edu
Received: from fizzy by franz (5.5/3.14)
id AA01194; Mon, 14 Jul 86 15:40:28 PDT
Received: by fizzy (4.12/3.14)
id AA10690; Mon, 14 Jul 86 15:40:01 pdt
Return-Path: <fizzy!jkf>
Message-Id: <8607142240.AA10690@fizzy>
To: Robert W. Kerns <ucbkim!YUKON.SCRC.Symbolics.COM!RWK>
Cc: common-lisp@su-ai.arpa
Subject: Re: GC, exit-to-system
In-Reply-To: Your message of Mon, 14 Jul 86 16:41:00 EDT.
<860714164119.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Mon, 14 Jul 86 15:39:58 PDT
>> I think this would just encourage people to write non-portable
>> code. Calling the GC from a program may make it work better on
>> one implementation, while making it work not at all, or extremely
>> poorly, on another.
As you know, many implementations enable the user to explicitly invoke a
gc. Are you saying that we would be better off if each implementation
chose a different name for this function as that would discourage it's
use in portable programs? This would certainly be a novel idea in
portable language design. [and a poor one, in my opinion].
In my experience, the gc function is typically used before running
benchmarks (and benchmarks seem to be the code that most people are
porting between implementations at this time.) It is extremely
unlikely that anyone would put a call to gc in their 'portable
program'.
- john foderaro
Franz Inc.
∂14-Jul-86 1658 franz!fizzy!jkf@kim.Berkeley.EDU Re: Proposals 2, 3, & 4
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 14 Jul 86 16:57:51 PDT
Received: by kim.Berkeley.EDU (5.53/1.14)
id AA13384; Mon, 14 Jul 86 16:58:41 PDT
From: franz!fizzy!jkf@kim.berkeley.edu
Received: from fizzy by franz (5.5/3.14)
id AA01386; Mon, 14 Jul 86 15:57:46 PDT
Received: by fizzy (4.12/3.14)
id AA10715; Mon, 14 Jul 86 15:57:18 pdt
Return-Path: <fizzy!jkf>
Message-Id: <8607142257.AA10715@fizzy>
To: "Scott E. Fahlman" <ucbkim!C.CS.CMU.EDU!Fahlman>
Cc: common-lisp@su-ai.arpa
Subject: Re: Proposals 2, 3, & 4
In-Reply-To: Your message of Mon, 14 Jul 86 14:18:00 EDT.
<FAHLMAN.12222664034.BABYL@C.CS.CMU.EDU>
Date: Mon, 14 Jul 86 15:57:15 PDT
>> The primitive function would return a sequence something like this
>> (a b c &optional d e &rest r &key x y &allow-other-keys)
>>
>> or a keyword signifying that it doesn't have the information.
>> I don't like this approach at all. It seems to make more work for
>> everyone and to require that all this information be carried around in
>> an inefficient and hard-to-parse form.
Inefficient? Actually this holds the minimum amount of information
necessary to return the values in proposals 2 through 4 (if you must
return symbols, and I think you must). I just did a check of the
lisp package functions. The info is:
627 functions
max length of above type of list: 13
total length of all lists: 1510
average size of list 2.4
functions with optional 105
functions with rest 69
functions with key 94
I've used a list to hold the information. A vector may
be more space efficient, it depends on the overhead per vector since the
average list size is small.
Notice that there are few functions with rest and key arguments. Thus if
you use a fixed size structure for holding the key and rest
information, you will be wasting those slots most of the time.
As for hard to parse, it is actually quite easy to parse, and as I
said before the source code for functions to do the parsing and to
return the information requested by proposals 2,3 and 4 should be part
of the specification.
- john foderaro
Franz Inc.
∂14-Jul-86 1753 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM GC, exit-to-system
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 14 Jul 86 17:53:12 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 41053; Mon 14-Jul-86 17:40:21 EDT
Date: Mon, 14 Jul 86 17:38 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: GC, exit-to-system
To: RWK@SCRC-STONY-BROOK.ARPA, Moon@SCRC-STONY-BROOK.ARPA,
franz!fizzy!jkf@kim.berkeley.edu
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860714164119.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <860714173834.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
My experience with large portable programs that GC a lot suggests that trying
to make a portable GC abstraction doesn't work for reasons related not only
to what kind of GC is involved but also because of time requirements. eg,
sometimes you want to call GC because you're about to dump a system and maybe
then you don't care how long it will take. other times, you are calling it just
because you learned to program in Maclisp where GC'ing was so fast you didn't
care. eg, Maclisp GC was fast enough that although it would have slowed things
down slightly, you could almost have gotten away with calling it every time
you thought there might be garbage to collect. That certainly isn't true for
some GC's I've run into. eg, if they take more than 5 seconds, I may not be
willing to wait. Certainly if they take more than a minute, I am not willing to
wait. Also, implementations differ in whether there will be garbage to collect.
If you have the ephemeral GC running on the 3600, there may not be any point
to trying to GC because the ephemeral GC is working well enough.
What I'm getting at is that my initial reaction is that what I was doing
was saying
(DEFUN GC ()
#+3600 NIL
#+ABC (GC)
#+DEF (SYSTEM:GC-INTERNAL T NIL 3)
#+GHI (GC:DO-IT)
...)
but that I've found from experience that although I know what GC people would
have provided me, I'm not happy with the performance of those GCs -- not in
the sense that they don't do reasonable things, but in the sense that they
do anything even remotely comparable. Each one was written by an implementor
who had certain priorities in mind. eg, the folks on micros probably have fast
GC's so they like to be able to call them, but the folks on machines that have
big disks and big virtual memory areas and bad paging performance are in a
different boat.
In fact, I should underscore the fact that I'm sufficiently content with making
(GC) just do nothing on the 3600 as long as the ephemeral GC is running that I'm
really not trying to say that Symbolics somehow would be the one to suffer for
this decision. I'm wearing my portable-code-writer's hat when I insist that
I might want a GC that let me have all sorts of hairy keywords that said things
like
(GC :UNLESS-THERES-LOTS-OF-FREE-MEMORY T
:UNLESS-IT-WILL-TAKE-LONGER-THAN-N-SECONDS 11
:ONLY-IF-IT-WOULD-RECLAIM-FUNCTION-SPACE T
:ONLY-IF-MACLISP-STYLE-GCTWA-IS-SUPPORTED T
...)
... but I just don't think that something as blunt as a single function is going
to cut it.
Also, I think the whole point of GC is to optimize those features of the
implementation which are beyond the scope of the CL spec, and I think that's a
good hint that we're going in the wrong direction by suggesting that we can
do such optimization with a blindfold on.
By the way, it seems to me that the purpose of the GC is to be invisible to
the user. Lisp is really organized around the idea that you don't think about
memory management. If we can't even write reasonable, portable programs without
having to call GC explicitly, I think there may be something more fundamentally
wrong with the language.
I'd probably suggest we introduce RECLAIM in CL before we introduce GC just
because it is at least possible to define in a portable way -- albeit horribly
dangerous, as anyone who's tried to use it in serious code has no doubt figured
out.
∂14-Jul-86 1846 FAHLMAN@C.CS.CMU.EDU Proposals 2, 3, & 4
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Jul 86 18:46:10 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 14 Jul 86 21:46:23-EDT
Date: Mon, 14 Jul 1986 21:46 EDT
Message-ID: <FAHLMAN.12222745499.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: franz!fizzy!jkf@KIM.BERKELEY.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: Proposals 2, 3, & 4
Well, your proposal isn't as bad as I thought in terms of storage
demands. Thanks for digging up the relevant facts. We'd probably all
be better off if we used more facts and fewer hunches.
Your proposal may be a good alternative to proposal 4. It takes a bit
of extra storage to put the & keywords into the list, but probably not
enough to matter.
A question facing both your proposal and proposal 4 is whether we should
save the parameter names as symbols or as strings. You seem rather
certain that symbols, in the proper package, are necessary. Do you have
some application in mind where this would matter? The debugging-type
things I had in mind would get along just fine with strings, and symbols
cost considerably more in storage.
I still think that we should keep FUNCTION-PARAMETERS and maybe
FUNCTION-PARAMETER-RANGE as they are defined in the proposals 2 and 3.
A lot of implementations have this information represented in their
function objects in ways which are carefully optimized for quick access
at function-call time. To implement proposals 2 and 3, they would just
have to develop ways of accessing this info (plus maybe keeping around a
keyword list for keyword functions). Accessing this internal info would
in many cases be quicker than extracting the same information from a
list in the format you propose, even if that list is around. An
implementor might choose to extract this info from a stored arglist
instead, but we shouldn't require that or even encourage it.
-- Scott
∂14-Jul-86 1932 kessler%utah-orion@utah-cs.arpa Definition time macros
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 19:32:31 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA01140; Mon, 14 Jul 86 20:32:31 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA13084; Mon, 14 Jul 86 20:32:27 MDT
Date: Mon, 14 Jul 86 20:32:27 MDT
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
Message-Id: <8607150232.AA13084@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Definition time macros
I also believe in the CL goal of the exact same semantics between the
compiler and interpreter. Its hard enough teaching students Lisp when you
also have to discuss the grungy details of the differences between compiled
and interpreted code. However, one big hole in the CL scheme is that it
is not specified that all macros must expand at definition time. That is the
only way that one can force the same semantics.
1) Does CL say anything that forbids a system from expanding macros at
function definition time?
2) Would it be reasonable to add this requirement to the standard?
By the way, I don't like the technique mentioned earlier where one may only
specify patterns for macros. When writing macros, I want the full power of
Lisp in order to generate the new code.
Bob.
∂14-Jul-86 1944 kessler%utah-orion@utah-cs.arpa GC and BYE
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 19:44:05 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA01241; Mon, 14 Jul 86 20:44:07 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA13096; Mon, 14 Jul 86 20:44:00 MDT
Date: Mon, 14 Jul 86 20:44:00 MDT
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
Message-Id: <8607150244.AA13096@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: GC and BYE
I'd like to put my vote in for these two functions. Especially BYE, QUIT or
EXITLISP or whatever. I recently tried out the new HP Common Lisp. After
experimenting for a few minutes, I decided to exit the lisp. I then had to
find the documentation to see how one did it. It was a real pain.
While we are on the subject, how about another feature. PSL had the ability
to turn on a switch that specified that all future function definitions would
be compiled instead of interpreted. It made for a very nice programming
environment to switch between compiled and interpreted code. Its also
much easier to turn on the switch instead of changing all function definitions
to either:
(defun foo ... )
(compile 'foo)
-or-
(compile 'foo #'(lambda ...))
1) Should this kind of feature be system dependent?
2) Switches aren't really present in CL, is there a better way?
Bob.
∂14-Jul-86 2316 oster%ucblapis@BERKELEY.EDU DESCRIBE-ARGUMENTS
Received: from UCBVAX.Berkeley.EDU by SU-AI.ARPA with TCP; 14 Jul 86 23:15:50 PDT
Received: by ucbvax (5.53/1.14)
id AA12260; Mon, 14 Jul 86 23:16:34 PDT
Received: by ucbjade.Berkeley.Edu (5.31 (CFC 4.21)/5.6.1)
id AA13382; Mon, 14 Jul 86 16:37:00 PDT
Received: by ucblapis.Berkeley.Edu (4.19/5.6)
id AA04256; Mon, 14 Jul 86 16:36:46 pdt
Date: Mon, 14 Jul 86 16:36:46 pdt
From: oster%ucblapis@BERKELEY.EDU (David Phillip Oster)
Message-Id: <8607142336.AA04256@ucblapis.Berkeley.Edu>
To: common-lisp@su-ai.arpa
Subject: DESCRIBE-ARGUMENTS
franz!fizzy!jkf in Mesg 14 suggests that DESCRIBE-ARGUMENTS return a list like:
(a b c &optional d e &rest r &key x y &allow-other-keys)
Fahlman@c.cs.cmu.edu says that a list is hard to parse and a string should
be returned instead. Is this a joke? Where are the ":-)"s?
The function exists in Interlisp and is very useful.
∂15-Jul-86 0055 Pavel.pa@Xerox.COM Re: DESCRIBE-ARGUMENTS
Received: from XEROX.COM by SU-AI.ARPA with TCP; 15 Jul 86 00:51:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUL 86 00:51:38 PDT
Date: 15 Jul 86 00:51 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: DESCRIBE-ARGUMENTS
In-reply-to: oster%ucblapis@BERKELEY.EDU (David Phillip Oster)'s message
of Mon, 14 Jul 86 16:36:46 pdt
To: oster%ucblapis@BERKELEY.EDU
cc: common-lisp@su-ai.arpa
Message-ID: <860715-005138-2891@Xerox>
Date: Mon, 14 Jul 86 16:36:46 pdt
From: oster%ucblapis@BERKELEY.EDU (David Phillip Oster)
franz!fizzy!jkf in Mesg 14 suggests that DESCRIBE-ARGUMENTS return a
list like:
(a b c &optional d e &rest r &key x y &allow-other-keys)
Fahlman@c.cs.cmu.edu says that a list is hard to parse and a string
should
be returned instead. Is this a joke? Where are the ":-)"s?
The function exists in Interlisp and is very useful.
Actually, the function in Interlisp doesn't put any of those new-fangled
&-keywords in its result, since Interlisp doesn't have those features.
It is the case, however, that Xerox Common Lisp stores a list just
exactly like that in every compiled function...
Pavel
∂15-Jul-86 0713 FAHLMAN@C.CS.CMU.EDU DESCRIBE-ARGUMENTS
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 07:13:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 15 Jul 86 10:12:02-EDT
Date: Tue, 15 Jul 1986 10:11 EDT
Message-ID: <FAHLMAN.12222881230.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: oster%ucblapis@λBERKELEY.EDU (David Phillip Oster)λ
Cc: common-lisp@SU-AI.ARPA
Subject: DESCRIBE-ARGUMENTS
In-reply-to: Msg of 14 Jul 1986 19:36-EDT from oster%ucblapis at BERKELEY.EDU (David Phillip Oster)
Fahlman@c.cs.cmu.edu says that a list is hard to parse and a string should
be returned instead. Is this a joke? Where are the ":-)"s?
The function exists in Interlisp and is very useful.
Well, I've spent a couple of days working on it, and now I think I see
how to extract arg-counts and stuff like that from the incredibly
obscure format that Foderaro proposes. I think we could write all of
the necessary functions in under a week. <= BEWARE! ATTEMPTED SARCASM!
What I was trying to say was that in a lot of implementations the kind
of information that would be returned by FUNCTION-PARAMETERS is sitting
around in already-parsed form so that the implementation can check for
legal calls quickly. Given that, why pack it into a list that then has
to be grovelled to get what you want. Various people have been arguing
that this call needs to be fast and non-consing. The "difficulty" I was
referring to was not the difficulty of writing the code, but the time
required to extract the various kinds of useful info from this list
format, as compared to keeping this around in some pre-digested format.
-- Scott
∂15-Jul-86 0722 @MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA Re: DESCRIBE-ARGUMENTS
Received: from LIVE-OAK.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86 07:21:54 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 4220; 15 Jul 86 10:23:09-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 29015; Tue 15-Jul-86 10:23:29-EDT
Date: Tue, 15 Jul 86 10:20 EST
From: mike%gold-hill-acorn@mit-live-oak.arpa
To: Pavel.pa@Xerox.COM
Reply-to: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: Re: DESCRIBE-ARGUMENTS
Cc: oster%ucblapis@BERKELEY.EDU, common-lisp@su-ai.arpa
Date: 15 Jul 86 00:51 PDT
From: Pavel.pa@Xerox.COM
Date: Mon, 14 Jul 86 16:36:46 pdt
From: oster%ucblapis@BERKELEY.EDU (David Phillip Oster)
franz!fizzy!jkf in Mesg 14 suggests that DESCRIBE-ARGUMENTS return a
list like:
(a b c &optional d e &rest r &key x y &allow-other-keys)
Fahlman@c.cs.cmu.edu says that a list is hard to parse and a string
should
be returned instead. Is this a joke? Where are the ":-)"s?
The function exists in Interlisp and is very useful.
....
It is the case, however, that Xerox Common Lisp stores a list just
exactly like that in every compiled function...
Pavel
Info is also lost if it is a string. Package qualifiers are needed to
tell which variables are being bound if any of the symbols in the arglist
are specvars.
...mike beckerle
Gold Hill Computers
∂15-Jul-86 0738 FAHLMAN@C.CS.CMU.EDU Definition time macros
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 07:38:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 15 Jul 86 10:37:06-EDT
Date: Tue, 15 Jul 1986 10:36 EDT
Message-ID: <FAHLMAN.12222885796.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: kessler%utah-orion@λutah-cs.arpa (Robert Kessler)λ
Cc: common-lisp@SU-AI.ARPA
Subject: Definition time macros
In-reply-to: Msg of 14 Jul 1986 22:32-EDT from kessler%utah-orion at utah-cs.arpa (Robert Kessler)
I also believe in the CL goal of the exact same semantics between the
compiler and interpreter. Its hard enough teaching students Lisp when you
also have to discuss the grungy details of the differences between compiled
and interpreted code. However, one big hole in the CL scheme is that it
is not specified that all macros must expand at definition time. That is the
only way that one can force the same semantics.
1) Does CL say anything that forbids a system from expanding macros at
function definition time?
This is legal, I think. Since the book explicitly gives permission to
compile code on sight instead of having a real interpreter, it must
follow that defun-time expansion of macros is legal. H-P currently does
this, as I'm sure you know.
2) Would it be reasonable to add this requirement to the standard?
In my opinion, it should not even be encouraged, let alone required.
I've been discussing the desirabilty of doing DEFUN-time expansion and
other source-level transforms with some of the H-P people since I
started using their system. In my view, the only reason to have an
interpreter around at all is that it is much easier to debug code if it
is still more or less what you wrote. Once the proverbial clever
compiler has come in and changed everything beyond recognition, you may
as well let it go ahead and finish compiling. Just doing the expansions
and source-level transforms gets you the worst of both worlds: the code
is unreadable, but not fast.
Before someone points it out, I know that with a couple of man-years of
work, one can develop a memoizing system and matching debugging tools so
that the compiler's alterations become invisible to the user most of the
time, but these things never quite get the job done right, in my
experience.
So it is a desirable goal to have interpreted code exactly match
compiled code, but it is also a desirable goal to have a good
source-language debugging environment in the interpreter. It's a
trade-off. In my experience, the differences introduced by expanding
macros at execution time, rather than definition time, are not
troublesome in practice and are not the kind of thing that a beginner is
going to run into. (Actually, that statement assumes that the compiler
does macro-expansion and then code generation in the same recursive
descent. If all of the source-level transforms are done in a pre-pass,
as H-P likes to do, you can get some more glaring discrepancies, and
defun-time expansion looks a bit more important.)
-- Scott
∂15-Jul-86 0752 kessler%cons@utah-cs.arpa Definition time macros
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 15 Jul 86 07:51:38 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA06933; Tue, 15 Jul 86 08:51:30 MDT
Received: by cons.ARPA (4.30/4.40.2)
id AA13707; Tue, 15 Jul 86 08:54:44 mdt
Date: Tue, 15 Jul 86 08:54:44 mdt
From: kessler%cons@utah-cs.arpa (Robert R. Kessler)
Message-Id: <8607151454.AA13707@cons.ARPA>
To: Fahlman@c.cs.cmu.edu
Cc: common-lisp@su-ai.arpa
In-Reply-To: "Scott E. Fahlman"'s message of Tue, 15 Jul 1986 10:36 EDT
Subject: Definition time macros
>I've been discussing the desirabilty of doing DEFUN-time expansion and
>other source-level transforms with some of the H-P people since I
>started using their system. In my view, the only reason to have an
>interpreter around at all is that it is much easier to debug code if it
>is still more or less what you wrote. Once the proverbial clever
>compiler has come in and changed everything beyond recognition, you may
>as well let it go ahead and finish compiling. Just doing the expansions
>and source-level transforms gets you the worst of both worlds: the code
>is unreadable, but not fast.
>
This is a good point that I had not considered. I agree that its
important to have interpreted code present (one of the big loses of
the ExperLisp system on the Macintosh is that its compiler only - that
makes debugging very difficult).
>...
>
>So it is a desirable goal to have interpreted code exactly match
>compiled code, but it is also a desirable goal to have a good
>source-language debugging environment in the interpreter. It's a
>trade-off. In my experience, the differences introduced by expanding
>macros at execution time, rather than definition time, are not
>troublesome in practice and are not the kind of thing that a beginner is
>going to run into.
I can only say that in quite a number of times in teaching Lisp, I
have seen the students "discover" that one can do anything one wants in
a macro and invariably screw themselves. I think that some of it may
be legitimate because of the lack of Fexprs. They don't seem to
realize that its easy to write a macro to quote the arguments that
then calls the auxillary function. As students typically do, they
look for the short cut and combine it all into one macro. sigh...
> ... (Actually, that statement assumes that the compiler
>does macro-expansion and then code generation in the same recursive
>descent. If all of the source-level transforms are done in a pre-pass,
>as H-P likes to do, you can get some more glaring discrepancies, and
>defun-time expansion looks a bit more important.)
>
>-- Scott
>
Bob.
∂15-Jul-86 0854 franz!fizzy!jkf@kim.Berkeley.EDU Re: Proposals 2, 3, & 4
Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 15 Jul 86 08:54:30 PDT
Received: by kim.Berkeley.EDU (5.53/1.14)
id AA27495; Tue, 15 Jul 86 08:55:24 PDT
From: franz!fizzy!jkf@kim.berkeley.edu
Received: from fizzy by franz (5.5/3.14)
id AA05730; Tue, 15 Jul 86 07:56:34 PDT
Received: by fizzy (4.12/3.14)
id AA11721; Tue, 15 Jul 86 07:56:06 pdt
Return-Path: <fizzy!jkf>
Message-Id: <8607151456.AA11721@fizzy>
To: "Scott E. Fahlman" <ucbkim!C.CS.CMU.EDU!Fahlman>
Cc: common-lisp@su-ai.arpa
Subject: Re: Proposals 2, 3, & 4
In-Reply-To: Your message of Mon, 14 Jul 86 21:46:00 EDT.
<FAHLMAN.12222745499.BABYL@C.CS.CMU.EDU>
Date: Tue, 15 Jul 86 07:56:04 PDT
>> Your proposal may be a good alternative to proposal 4. It takes a bit
>> of extra storage to put the & keywords into the list, but probably not
>> enough to matter.
Actually storing the & keywords in the list saves space overall since
it then doesn't require you to have fixed, normally empty, slots to
hold rest, optional and key symbols.
>> A question facing both your proposal and proposal 4 is whether we should
>> save the parameter names as symbols or as strings. You seem rather
>> certain that symbols, in the proper package, are necessary. Do you have
>> some application in mind where this would matter?
Since a formal parameter can be a special variable, a string naming
the special variable is ambiguous without the package information.
For debugging interpreted code you would like the symbol for each of
the formal parameters since that would permit the debugger to poke through
the lexical environment an locate the current value of that argument.
[You can imagine cases where using a string for the name would be
ambiguous.] If symbols are to be used for interpreted code, then
using strings for compiled code would be a pain.
>> The debugging-type
>> things I had in mind would get along just fine with strings, and symbols
>> cost considerably more in storage.
Most people tend to use the name parameter names over and over again.
Recall that for the 627 functions in our lisp package, the total
length of the parameter description lists is 1510. There are only 248
unique symbols in that list of 1510. I think that in this case
saving the parameters as symbols saves a significant amount of space
over saving the parameters as strings (unless you simulate a package
by creating a hash table of parameter name strings, in which case
it is hard to say which is more space efficient, it depends on how many
of those 248 symbols would have existed anyway).
>> I still think that we should keep FUNCTION-PARAMETERS and maybe
>> FUNCTION-PARAMETER-RANGE as they are defined in the proposals 2 and 3.
>> A lot of implementations have this information represented in their
>> function objects in ways which are carefully optimized for quick access
>> at function-call time.
What you're saying is that one implementation's primitive is another
implementation's higher level function. I agree. We can't force
everyone to use the same primitive at this stage. I suggest this
solution:
1. The language specification should pick the simplest primitive
(which I believe is the argument list that I proposed) and write
the other function-parameter-whatever functions in terms of that
primitive. [This adds one more function to the proposed list of
function parameter functions you proposed]
2. implementions are free to write any of the functions in terms of
any of the other functions, and they are encouraged to make each
function-parameter-whatever function as cheap to execute as
possible (e.g. use caching for those functions that must do
some work).
- john foderaro
Franz Inc.
∂15-Jul-86 0903 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: GC, exit-to-system
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 15 Jul 86 09:03:42 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 41634; Tue 15-Jul-86 12:04:38 EDT
Date: Tue, 15 Jul 86 12:03 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: GC, exit-to-system
To: franz!fizzy!jkf@kim.berkeley.edu
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8607142240.AA10690@fizzy>
Message-ID: <860715120338.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
The problem is that GC works so differently from one implementation to
the next. If someone would try to make an explicit proposal for the
addition of a GC function, I think this would become clear. Exactly
what is the new proposed GC function supposed to do? Exactly what are
the criteria by which I could know whether my Common Lisp implementation
was in conformance with the spec regarding GC, or not? Can a spec be
written that is specific enough that a program could usefully depend on
the GC function in any way, without being so specific that some
implementations could not conform to it reasonably? I don't think so.
In order for the Common Lisp specification to include a GC function, the
Common Lisp specification must include a concept of garbage collection:
what it means, what it is defined to do and not do, etc. The function
isn't really the hard part; the concept is the hard part.
I feel the same way about the BYE function. Common Lisp would need a
concept of "returning to the operating system" or something like that.
Some implementations do not have any such thing. It is out of the scope
of Common Lisp.
The only way I can imagine that such functions would be acceptable would
be if their definition said something like "In some implementations,
this function is allowed to do absolutely nothing". They would
therefore have to be considered part of a "user interface" rather than
part of the language, since no portable program could sensibly call
them. I think we should try to confine ourselves to the language
business. We have more than enough work ahead of us in that department!
∂15-Jul-86 1031 @MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA Definition time macros
Received: from LIVE-OAK.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86 10:31:06 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 4237; 15 Jul 86 13:27:48-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 29030; Tue 15-Jul-86 11:09:44-EDT
Date: Tue, 15 Jul 86 11:07 EST
Sender: mike%gold-hill-acorn@mit-live-oak.arpa
To: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
From: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: Definition time macros
Cc: common-lisp@su-ai.arpa
Date: Mon, 14 Jul 86 20:32:27 MDT
From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
I also believe in the CL goal of the exact same semantics between the
compiler and interpreter. Its hard enough teaching students Lisp when you
also have to discuss the grungy details of the differences between compiled
and interpreted code. However, one big hole in the CL scheme is that it
is not specified that all macros must expand at definition time. That
is the only way that one can force the same semantics.
1) Does CL say anything that forbids a system from expanding macros at
function definition time?
I think not.
2) Would it be reasonable to add this requirement to the standard?
........
Bob.
On page 143 of CLtL, paragraph 4 indicates that a compiled semantics
for macros is valid also for interpreted code, but it also states
that "an implementation has great latitude in deciding exactly when
to expand macro calls within a program". I'd like to see this
tightened up to indicate that macros expand once, as in a compiler,
and are not expanded over and over each time an expression is
interpreted. In the interpreter they need not expand at definition
time, but can expand at first evaluation using a "splicing macro"
technique.
...mike beckerle
Gold Hill Computers
∂15-Jul-86 1157 FAHLMAN@C.CS.CMU.EDU Definition time macros
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 11:57:36 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 15 Jul 86 14:56:06-EDT
Date: Tue, 15 Jul 1986 14:55 EDT
Message-ID: <FAHLMAN.12222932936.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: mike%gold-hill-acorn@LIVE-OAK.LCS.MIT.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: Definition time macros
In-reply-to: Msg of 15 Jul 1986 12:07-EDT from mike%gold-hill-acorn at mit-live-oak.arpa
I'd like to see this
tightened up to indicate that macros expand once, as in a compiler,
and are not expanded over and over each time an expression is
interpreted.
I feel very strongly that requiring this is a bad idea.
∂15-Jul-86 1242 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Definition time macros
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 15 Jul 86 12:41:34 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 41906; Tue 15-Jul-86 15:42:13 EDT
Date: Tue, 15 Jul 86 15:40 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Definition time macros
To: Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12222932936.BABYL@C.CS.CMU.EDU>
References: The message of 15 Jul 86 12:07-EDT from mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA
Message-ID: <860715154038.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 15 Jul 1986 14:55 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Date: 15 Jul 86 12:07-EDT
From: mike%gold-hill-acorn@LIVE-OAK.LCS.MIT.EDU
I'd like to see this tightened up to indicate that macros expand
once, as in a compiler, and are not expanded over and over each
time an expression is interpreted.
I feel very strongly that requiring this is a bad idea.
I feel very strongly that requiring this would be a very good idea. I
think Scheme has a big lesson to teach us here. They have made lexical
analysis occur at a well-defined time and it has made program-understanding
a much more straightforward issue.
For example, in the current state of confusion, the fact that there is
no definite time at which macro expansion occurs means that
(DEFUN FOO (X) (IF X (BAR) (BAR)))
can have its behavior depend on X in interpreted code but not compiled
(assuming BAR is a macro that does not expand into a reference to X),
especially if runtime macro caching is being done. This could be baffling
to naive users and is quite irritating to some of us sophisticated users.
I also believe there are a number of glaring uglinesses in the language
which can be fairly directly attributed to the decision to not have a
well-defined ENCLOSE time. Among these are the assymetry between interpreted
and compiled "#," and the weird definition of EVAL-WHEN. I could and would
make proposals to improve/fix both of these problems if we had a well-defined
ENCLOSE time.
All linguistic issues aside, it's also the case that since implementations
are currently free to vary on this, the debugging skills a programmer learns
in one implementation may not carry over to another. In fact, those skills
may work against the programmer if he has a mindset that leads him to make
assumptions as in the case of the FOO definitino above which don't pan out.
∂15-Jul-86 1531 FAHLMAN@C.CS.CMU.EDU Definition time macros
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 15:20:23 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 15 Jul 86 18:18:46-EDT
Date: Tue, 15 Jul 1986 18:18 EDT
Message-ID: <FAHLMAN.12222969839.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Definition time macros
In-reply-to: Msg of 15 Jul 1986 15:40-EDT from Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
No doubt about it, one can develop a cleaner semantics for a language
without an interpreter. Cleaner still is to require all of the code to
be presented at one time so that it can be compiled into a block and so
that everything can be checked statically -- none of this incremental
stuff. There are already lots of languages like that, and I'd hate to
see Common Lisp become one of them.
OK, this exaggerates your position, but I think that expanding macros
just once, at "enclose time" is a step in that direction.
-- Scott
∂15-Jul-86 1619 RAM@C.CS.CMU.EDU Proposals 2, 3, & 4
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 16:17:37 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 15 Jul 86 19:16:02-EDT
Date: Tue, 15 Jul 1986 19:15 EDT
Message-ID: <RAM.12222980244.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: franz!fizzy!jkf@KIM.BERKELEY.EDU
Cc: common-lisp@SU-AI.ARPA, fahlman@C.CS.CMU.EDU
Subject: Proposals 2, 3, & 4
In-reply-to: Msg of 15 Jul 1986 10:56-EDT from franz!fizzy!jkf at kim.berkeley.edu
Date: Tuesday, 15 July 1986 10:56-EDT
From: franz!fizzy!jkf at kim.berkeley.edu
To: Scott E. Fahlman <ucbkim!C.CS.CMU.EDU!Fahlman at kim.berkeley.edu>
cc: common-lisp at su-ai.arpa
Re: Proposals 2, 3, & 4
Actually storing the & keywords in the list saves space overall since
it then doesn't require you to have fixed, normally empty, slots to
hold rest, optional and key symbols.
The point is that nearly all implementations will already have the arg
count information stored in some other way so that their call
mechanisms can work. It is desirable to separate the mandatory
semantics of the call interface from the informational content of
parameter names.
For debugging interpreted code you would like the symbol for each of
the formal parameters since that would permit the debugger to poke through
the lexical environment an locate the current value of that argument.
[You can imagine cases where using a string for the name would be
ambiguous.] If symbols are to be used for interpreted code, then
using strings for compiled code would be a pain.
Debuggers are blatently non-portable anyway. I question that there is
any use for paramater names in portable code other than simple
display. A debugger is certainly not an example of such a use.
>> The debugging-type
>> things I had in mind would get along just fine with strings, and symbols
>> cost considerably more in storage.
Most people tend to use the name parameter names over and over again.
Recall that for the 627 functions in our lisp package, the total
length of the parameter description lists is 1510. There are only 248
unique symbols in that list of 1510. I think that in this case
saving the parameters as symbols saves a significant amount of space
over saving the parameters as strings (unless you simulate a package
by creating a hash table of parameter name strings, in which case
it is hard to say which is more space efficient, it depends on how many
of those 248 symbols would have existed anyway).
This argument is plausible, but incorrect. Changing to a string
representation in Spice Lisp significantly reduced storage. This is
partly due to the use of a single string for the entire argument list.
Some sharing of strings also exists, since our fasl dumper makes equal
strings EQ, thus making identical strings in the same file EQ. It is
also significant that boxed symbol, package and list storage was
replaced with unboxed string storage. This change eliminated >1000
(10%) of the symbols in our core image.
I think that using the arglist to indicate argument info is silly
unless the paramater names are required to be right, and that it is
unreasonable to require the names to be stored. The semantics of the
language require the storage of the information returned by
FUNCTION-PARAMETERS, so every implementation must have some way to
access this information.
Rob
∂15-Jul-86 1651 snyder%hplsny@hplabs.HP.COM Re: Definition time macros
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 15 Jul 86 16:49:53 PDT
Received: from hplsny by hplabs.HP.COM ; Tue, 15 Jul 86 16:47:43 pdt
Received: by hplsny ; Tue, 15 Jul 86 16:48:01 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8607152348.AA01682@hplsny>
Date: Tue, 15 Jul 86 16:47:49 PDT
Subject: Re: Definition time macros
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 15-Jul-86 18:18:00
X-Mailer: NMail [$Revision: 2.5 $]
No doubt about it, one can develop a cleaner semantics for a language
without an interpreter. Cleaner still is to require all of the code to
be presented at one time so that it can be compiled into a block and so
that everything can be checked statically -- none of this incremental
stuff. There are already lots of languages like that, and I'd hate to
see Common Lisp become one of them.
OK, this exaggerates your position, but I think that expanding macros
just once, at "enclose time" is a step in that direction.
The package system is another step in that same direction (I can't write a
call to a function in another package unless the package has already been
defined); is it too late to take back the package system? Common Lisp
straddles the fence regarding easy incremental change versus static checking
and efficiency; the result is that interpreter/compiler consistency is still a
mess.
I think the idea of definition-time macro expansion should be explored; the
result might be worthwhile. Two problems have been mentioned: propagating the
effects of redefining a macro, and source-code debugging. I believe (without
proof) that these problems can be effectively solved in a development
environment (a delivery vehicle might choose not to solve these problems).
Dependency chains can be used to propagate changes. The expanded code can be
annotated to indicate its relationship with the source code.
Alan
-------
∂15-Jul-86 1805 Masinter.pa@Xerox.COM Proposals 2, 3, & 4
Received: from XEROX.COM by SU-AI.ARPA with TCP; 15 Jul 86 18:05:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUL 86 18:04:53 PDT
Date: 15 Jul 86 18:04 PDT
From: Masinter.pa@Xerox.COM
Subject: Proposals 2, 3, & 4
to: common-lisp@SU-AI.ARPA
Message-ID: <860715-180453-3747@Xerox>
Argument lists in Interlisp are used for two purposed. One is for
applications that want a descriptive form, for printing out arguments on
the stack and in the editor; the other is for applications that need an
accurate list for advise, break and the like.
For most functions, the values returned are the same, but in some
situations, the descriptive arguments differ by being more elaborate,
having elipsis, arguments that aren't described (e.g., "secret"
optionals).
The language design principle that we have to be careful about with this
is that we want to retain some amount of modularity around exactly how a
function is implemented.
Currently
(defun foo (a) ...)
is equivalent to
(defun foo (&rest args)
(if (> (length args) 1) (error 'too-many-arguments ...))
(if (< (length args) 1) (error 'too-few-arguments ...))
(let ((a (car args)))
...)
Nothing so far in the language description prohibits that equivalence:
you can't "look inside" functions once they've been defined. We're now
adding something to the language that makes that equivalence no longer
valid, because you can tell what the parameter list is. Furthermore,
this example seems to contradict the assertion that the "semantics of
the language require the storage of the information returned by
FUNCTION-PARAMETERS, so every implementation must have some way to
access this information." unless access of the information were to
parse the disassembly of the definition somehow.
Interlisp has had an ARGLIST function which gives you back the argument
list of a function, but ARGLIST is really part of the *environment*
rather than part of the *language*. I would feel much more comfortable
with all of these proposals if they were somehow classified as that part
of the environment that Common Lisp standardized on.
This isn't bad. Despite its title, CLtL directly contains a number of
functions and features that are logically part of an environment rather
than part of the language, in part so that people can write portable
environment tools. Things like the stepper, evalhook, room, trace, the
description of the top level loop, the +, ++, +++ variables, etc. are
all part of Common Lisp the Environment. While there are many parts of
the environment that we will find difficulty agreeing upon, those
features for which "most implementations have something like this" are
good candidates. We've identified a number of potentially portable
environment tools which could make good use of a well-defined
function-argument-list access method.
Some specific comments on Proposal 2,3,4, given that they are part of
"environment" rather than "language":
There are two uses for argument lists in Interlisp: "accurate" argument
information for program-modifying programs like ADVISE and BREAK, and
"descriptive" argument information for
program-creation-and-debugging-aid programs like the debugger and
what-are-the-arguments-to-the-function-I'm-typing.
For many objects of examination these are the same, but not always.
Macros and special forms might have "descriptive" arguments, for
example; its as valid to ask about format of macro calls as it is
function calls. In some cases, the descriptive arguments contain
sequences (X1 ... XN) while the "real" argument list is (the Interlisp
equivalent of) &REST.
The differing requirements of these two applications have caused most of
the polarization of the discussion.
I will attempt a specific proposal that I think addresses the needs
independently.
∂15-Jul-86 1825 FAHLMAN@C.CS.CMU.EDU Definition time macros
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 18:25:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 15 Jul 86 21:23:41-EDT
Date: Tue, 15 Jul 1986 21:23 EDT
Message-ID: <FAHLMAN.12223003491.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Alan Snyder <snyder%hplsny@HPLABS.HP.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: Definition time macros
In-reply-to: Msg of 15 Jul 1986 19:47-EDT from Alan Snyder <snyder%hplsny at hplabs.HP.COM>
I think the idea of definition-time macro expansion should be explored; the
result might be worthwhile.
Well, I'm not against exploration. The H-P system does Defun-time
macro-expansion in the interpreter, so you're in an ideal position to
explore this, and H-P probably ought to be working on the problems you
mention: redefinition of macros and true source-level debugging.
Whenever this stuff is ready, let us know; due to H-P's generosity, a
lot of us will be in a position to try the resulting system and see if
we do indeed like it better than the current chaotic way of handling
macros. We can also see just how much work was required to solve the
problems, and whether it makes sense to require every implementation
install similar facilities.
We probably should not hold up the rest of the language design until
we've seen how this exploration comes out.
-- Scott
∂15-Jul-86 1848 RAM@C.CS.CMU.EDU Proposals 2, 3, & 4
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 18:48:47 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 15 Jul 86 21:47:43-EDT
Date: Tue, 15 Jul 1986 21:47 EDT
Message-ID: <RAM.12223007862.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Subject: Proposals 2, 3, & 4
In-reply-to: Msg of 15 Jul 1986 21:04-EDT from Masinter.pa at Xerox.COM
Date: Tuesday, 15 July 1986 21:04-EDT
From: Masinter.pa at Xerox.COM
To: common-lisp at SU-AI.ARPA
Re: Proposals 2, 3, & 4
...Furthermore,
this example seems to contradict the assertion that the "semantics of
the language require the storage of the information returned by
FUNCTION-PARAMETERS, so every implementation must have some way to
access this information." unless access of the information were to
parse the disassembly of the definition somehow.
In this case, the information is in fact stored in the code. I think
that it is reasonable to peek at stylized entry code to determine this
information. Although the fixed and optional arg counts are directly
represented in Spice Lisp, we would have to do some work to find out
the valid keywords.
Rob
∂15-Jul-86 2040 FAHLMAN@C.CS.CMU.EDU Feh!
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 20:40:06 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 15 Jul 86 23:39:00-EDT
Date: Tue, 15 Jul 1986 23:38 EDT
Message-ID: <FAHLMAN.12223028146.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Feh!
Proposal 4 is still on the list of things that will come before the
technical committee, but I personally no longer support it. It was a
very marginal idea anyway, with practically no uses in portable code. I
thought that if we could all agree on a reasonable format for returning
the names of the functions, whenever they are available, it might be of
some use to have a standard interface to this feature. As it stands,
we've got several different proposals on how to do this, each of which
seems to be best on some system or other, plus people who don't think
it's a good idea to peek inside the black box surronding a function's
implementation. I now believe we should forget this proposal and move
on to other issues of more importance. Users who want to get at a
function's argument list will just have to learn how their local system
encodes this information, if it does so at all.
I still support proposals 1, 2, and some form of 3. (I don't care much
whether it's 3A or 3B.)
-- Scott
∂15-Jul-86 2216 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Definition time macros
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 15 Jul 86 22:16:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 42046; Tue 15-Jul-86 17:49:52 EDT
Date: Tue, 15 Jul 86 17:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Definition time macros
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860715154038.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <860715174829.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 15 Jul 86 15:40 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Date: Tue, 15 Jul 1986 14:55 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Date: 15 Jul 86 12:07-EDT
From: mike%gold-hill-acorn@LIVE-OAK.LCS.MIT.EDU
I'd like to see this tightened up to indicate that macros expand
once, as in a compiler, and are not expanded over and over each
time an expression is interpreted.
I feel very strongly that requiring this is a bad idea.
I feel very strongly that requiring this would be a very good idea. I
think Scheme has a big lesson to teach us here. They have made lexical
analysis occur at a well-defined time and it has made program-understanding
a much more straightforward issue.
But they can't even agree among themselves what the semantics of macros should be!
∂15-Jul-86 2226 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Function-Parameter-names
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 15 Jul 86 22:23:13 PDT
Received: from umass-cs by csnet-relay.csnet id bf16484; 16 Jul 86 1:15 EDT
Date: Tue, 15 Jul 86 14:48 EST
From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To: Common-Lisp@SU-AI.ARPA
Subject: Function-Parameter-names
I can imagine someone trying to write an editor in portable CL who
would want to use function-parameter-names to provide the user with some
documentation. The list of symbols would be more valuable than a
describe-function-parameters function, because it allows the editor to
choose a format that fitwhere it has to. This can be important,
because many editors (i.e. Emacs &friends) devote most of the sceen
to displaying text leaving only a small area in which messages
have to appear.
ANother use for the symbols themselves is to check for declarations.
A code walker might not have access to the source code for a function,
but it could determine if any of the arguments are special variables
or something.
Chris Eliot
∂15-Jul-86 2313 RAM@C.CS.CMU.EDU
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 23:13:32 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 16 Jul 86 02:12:26-EDT
Date: Wed, 16 Jul 1986 02:12 EDT
Message-ID: <RAM.12223056074.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Proposal #1 (OPTIMIZE SAFETY)@C.CS.CMU.EDU
Cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of 13 Jul 1986 21:03-EDT from Scott E. Fahlman <Fahlman>
I have some comments regarding the interpretation of the optimize
declaration. I believe that the best way to use the optimize
information is to compare the values for different qualities. This is
because the decisions made by the compiler almost always are
trade-offs. You can trade speed for space and compilation speed for
speed, but absolute levels of optimization seem fairly meaningless.
It makes more sense to me to say that optional error checks would be
inhibited whenever SAFETY < SPEED.
Rob
∂16-Jul-86 0822 FAHLMAN@C.CS.CMU.EDU
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Jul 86 08:22:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 16 Jul 86 11:21:25-EDT
Date: Wed, 16 Jul 1986 11:21 EDT
Message-ID: <FAHLMAN.12223155990.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Cc: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of 16 Jul 1986 02:12-EDT from Rob MacLachlan <RAM>
I thought about allowing the inhibition if SAFETY < SPEED, but one might
also want to suppress the error checking to get more compact code or
even faster compilation, so the set of all the relative conditions gets
pretty hairy. That's why I picked absolute safety values for enabling
these checks.
-- Scott
∂16-Jul-86 1119 Parker.ES@Xerox.COM Tail Recursion in Common Lisp ???
Received: from XEROX.COM by SU-AI.ARPA with TCP; 16 Jul 86 11:19:28 PDT
Received: from Gamay.ms by ArpaGateway.ms ; 16 JUL 86 10:50:53 PDT
Date: 16 Jul 86 10:50:48 PDT (Wednesday)
Subject: Tail Recursion in Common Lisp ???
To: Common-Lisp@SU-AI.ARPA
From: James Parker <Parker.es@Xerox.COM>
cc: James Parker <Parker.es@Xerox.COM>
Message-ID: <860716-105053-4517@Xerox>
please excuse my ignorance. i'm learning Lisp from Abelson & Sussman,
and my Common Lisp book by Steele hasn't arrived yet.
does Common Lisp have tail recursion like Scheme, so that the syntatic
sugar for iterative loops is unnecessary ? if not, then is it being
considered ?
James
∂16-Jul-86 1242 Parker.ES@Xerox.COM Re: Tail Recursion in Common Lisp ???
Received: from XEROX.COM by SU-AI.ARPA with TCP; 16 Jul 86 12:41:59 PDT
Received: from Gamay.ms by ArpaGateway.ms ; 16 JUL 86 12:41:58 PDT
Date: 16 Jul 86 12:41:52 PDT (Wednesday)
Subject: Re: Tail Recursion in Common Lisp ???
In-reply-to: <8607161918.AA20027@utah-orion.ARPA>
To: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
From: James Parker <Parker.es@Xerox.COM>
cc: Common-Lisp@SU-AI.ARPA, James Parker <Parker.es@Xerox.COM>
Message-ID: <860716-124158-4659@Xerox>
stan,
> Tail recursion optimization . . . is a property of an implementation.
ok, ok, my question was sloppily worded. does the definition of Common
Lisp require that all implementations have tail recursion optimization ?
James
∂16-Jul-86 1249 FAHLMAN@C.CS.CMU.EDU Tail Recursion in Common Lisp ???
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Jul 86 12:49:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 16 Jul 86 15:48:02-EDT
Date: Wed, 16 Jul 1986 15:47 EDT
Message-ID: <FAHLMAN.12223204543.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: James Parker <Parker.es@XEROX.COM>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Tail Recursion in Common Lisp ???
In-reply-to: Msg of 16 Jul 1986 15:41-EDT from James Parker <Parker.es at Xerox.COM>
ok, ok, my question was sloppily worded. does the definition of Common
Lisp require that all implementations have tail recursion optimization ?
No. It has even been suggested that the current definition does not
allow tail-recursion optimization -- that's an issue we have to settle
soon, and I hope that we'll be able to work out a solution in which this
is allowed.
-- Scott
∂16-Jul-86 1337 willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Definition time macros
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 16 Jul 86 13:31:12 PDT
Received: from tektronix by csnet-relay.csnet id aj04469; 16 Jul 86 15:55 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA20872; Wed, 16 Jul 86 11:19:15 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA28807; Wed, 16 Jul 86 11:21:39 PDT
Message-Id: <8607161821.AA28807@tekchips.TEK>
To: common-lisp@SU-AI.ARPA
Subject: Re: Definition time macros
Organization: Tektronix, Inc., Beaverton, OR.
Date: 16 Jul 86 11:21:37 PDT (Wed)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
From: mike%gold-hill-acorn@LIVE-OAK.LCS.MIT.EDU
I'd like to see this tightened up to indicate that macros
expand once, as in a compiler, and are not expanded over
and over each time an expression is interpreted.
I feel very strongly that requiring this is a bad idea.
I feel very strongly that requiring this would be a very good idea.
I think Scheme has a big lesson to teach us here. They have made
lexical analysis occur at a well-defined time and it has made
program-understanding a much more straightforward issue.
But they can't even agree among themselves what the semantics of macros
should be!
It's useful to distinguish between agreement on what the semantics should
be, what the semantics will be, and what the semantics is. The designers
of Common Lisp clearly don't agree on what the semantics of macros should
be, are trying to agree on what the semantics will be, and are fairly well
agreed on what the semantics is. Thanks to Common Lisp, the designers of
Scheme felt free to worry about what the semantics should be instead of
worrying about a stopgap.
When Kent mentioned Scheme, he may have been thinking of the design
principle that the semantics of the language must make sense independently
of any strategies that might be used to implement it. To paraphrase Guy
Steele:
If, in the course of discussing a proposed language feature,
such terms as "interpreter", "compiler", or "macro expansion
time" come up, they serve as a warning!
For example, if a language feature doesn't make sense in an implementation
that doesn't have an interpreter, then the feature should be considered
only for inclusion in the programming environment section. This is
analogous to saying that a language feature that doesn't make sense in
an implementation that doesn't have a garbage collector should be
included, if at all, only in the programming environment section.
If the semantics were defined so that macros were expanded only once, then
implementors of programming environments could:
1. Let users see the macro-expanded code.
2. Do the work necessary to keep users from seeing code they didn't
write. (There's a continuum between 1 and 2, fortunately.)
3. Expand macros multiple times and advertise the bug as a feature.
The main difference between this and the status quo is that the status quo
has such a poorly defined semantics that implementors can expand macros
multiple times and advertise the bug as a feature without having to admit
that it's a bug. Neat trick.
William Clinger
Tektronix Computer Research Laboratory
∂16-Jul-86 1421 RPG Object-oriented-Programming Meeting at L&FP
To: Common-Lisp@SU-AI.ARPA
There will be an Object-Oriented Programming Meeting at 2:00 PM, Wednesday
August 6 in the Kresge Little Theater, which is right downstairs from
Kresge Auditorium, site of the Lisp Conference technical sessions.
-rpg-
∂16-Jul-86 1427 bond!m42!jap%ux63.bath.ac.uk@Cs.Ucl.AC.UK
Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 16 Jul 86 14:20:54 PDT
Received: from ux63.bath.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a002004; 15 Jul 86 22:04 BST
Date: 15 Jul 1986 22:03:30-GMT
From: bond!m42!jap%ux63.bath.ac.uk@Cs.Ucl.AC.UK
To: common-lisp <@Cs.Ucl.AC.UK:common-lisp@su-ai.arpa>
>From m42!jap Tue Jul 15 21:22:27 1986 remote from bond
Received: by bond.UUCP (4.12/4.7)
id AA15560; Tue, 15 Jul 86 21:22:27 bst
Received: by m42.UUCP (4.12/4.7)
id AA07132; Tue, 15 Jul 86 21:15:09 bst
Date: Tue, 15 Jul 86 21:15:09 bst
From: bond!m42!jap (Julian Padget)
Message-Id: <8607152015.AA07132@m42.UUCP>
To: bond!bath63!common-lisp%su-ai.arpa@uk.ac.ucl.cs
Subject: easier addressing
Thanks to the assistance of the folks in Utah, it might now perhaps be
easier for people in the US to get mail to eulisp (and to tender
requests for addition to the distribution). There is now an alias
eulisp@utah-cs.edu
(at least I presume it is edu these days) which will pass mail on to the
bboard at INRIA, in addition there is the alias
eulisp-request@utah-cs.edu
(same caveat) which will forward requests to Je'ro↑me Chailloux who is
the bboard maintaniner.
If demand is sufficient, it may also be worth inaugurating a North American
EuLISP discussion distribution in the same way, in order to cut down on
transatlantic traffic.
--Julian.
∂16-Jul-86 2043 OKUNO@SUMEX-AIM.ARPA RE: easier addressing for EuLISP discussions
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 16 Jul 86 20:43:01 PDT
Date: Wed 16 Jul 86 20:43:25-PDT
From: Hiroshi "Gitchang" Okuno <Okuno@SUMEX-AIM.ARPA>
Subject: RE: easier addressing for EuLISP discussions
To: common-lisp@SU-AI.ARPA
Message-ID: <12223291104.51.OKUNO@SUMEX-AIM.ARPA>
> If demand is sufficient, it may also be worth inaugurating a North
> American EuLISP discussion distribution in the same way, in order to
> cut down on transatlantic traffic.
I agree to this proposal. I think that the mailing list inside each
country should be maintained by each country, because it will reduce
the international communication costs drastically. In Japan, the
Common-Lisp bboard is distributed by NTT.
- Gitchang -
P.S. utah-cs.edu is wrong, because its official name is utah-cs.arpa
or utah-cs (without edu) at sumex-aim.stanford.edu - maybe at NIC.
-------
∂17-Jul-86 0754 BSG@ELEPHANT-BUTTE.SCRC.Symbolics.COM Tail Recursion in Common Lisp ???
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 17 Jul 86 07:54:27 PDT
Received: from SORA.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 43826; Thu 17-Jul-86 10:54:04 EDT
Date: Thu, 17 Jul 86 10:53 EDT
From: Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Tail Recursion in Common Lisp ???
To: Fahlman@C.CS.CMU.EDU, Parker.es@XEROX.COM
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12223204543.BABYL@C.CS.CMU.EDU>
Message-ID: <860717105303.8.BSG@SORA.SCRC.Symbolics.COM>
Date: Wed, 16 Jul 1986 15:47 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
ok, ok, my question was sloppily worded. does the definition of Common
Lisp require that all implementations have tail recursion optimization ?
No. It has even been suggested that the current definition does not
allow tail-recursion optimization -- that's an issue we have to settle
soon, and I hope that we'll be able to work out a solution in which this
is allowed.
-- Scott
"8/9 of this can of worms is below the surface". If the spec -allows-
tail-recursion optimization, and "my" implementation "supports"
tail-recursion, then "I" can, and most likely -will-, write a
"tail-recursive" program, which is theoretically portable, but in fact,
will blow the stack of most certified implementations that do not
"support" tail-recursion, and is thus, subtly, not portable.
∂17-Jul-86 0816 FAHLMAN@C.CS.CMU.EDU Tail Recursion in Common Lisp ???
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Jul 86 08:14:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 17 Jul 86 11:11:58-EDT
Date: Thu, 17 Jul 1986 11:11 EDT
Message-ID: <FAHLMAN.12223416424.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Bernard S. Greenberg" <BSG@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Tail Recursion in Common Lisp ???
In-reply-to: Msg of 17 Jul 1986 10:53-EDT from Bernard S. Greenberg <BSG at STONY-BROOK.SCRC.Symbolics.COM>
"8/9 of this can of worms is below the surface". If the spec -allows-
tail-recursion optimization, and "my" implementation "supports"
tail-recursion, then "I" can, and most likely -will-, write a
"tail-recursive" program, which is theoretically portable, but in fact,
will blow the stack of most certified implementations that do not
"support" tail-recursion, and is thus, subtly, not portable.
There are a million issues like this. For example, Common Lisp will
also allow theoretically portable programs that are 10 megabytes in
size, and that will blow the memory on small, non-virtual-memory
machines. We don't want to outlaw large programs or efficient compilers
or any compilation technique that leads to more effective use of
resources just because not everyone will have it and someone might be
screwed by that.
Portability is an important goal of Common Lisp, but not the only goal.
The best we can do in this case is to spell out clearly what is allowed
and what is required, and let programmers decide whether they want to
depend on non-required efficiency mechanisms, knowing that not all
machines will have them.
-- Scott
∂17-Jul-86 0901 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Tail Recursion in Common Lisp ???
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 17 Jul 86 09:01:48 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 43923; Thu 17-Jul-86 11:57:30 EDT
Date: Thu, 17 Jul 86 11:58 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Tail Recursion in Common Lisp ???
To: Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12223416424.BABYL@C.CS.CMU.EDU>
Message-ID: <860717115808.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Since the question of tail recursion comes up again and again, though, I
think the spec ought to make some explicit mention of the policy of the
language definition. The statement should indicate that if you write a
program that recurses heavily, thinking that this is not consuming stack
space due to tail recursion, you should be aware that not all
implementations have this property and your program might not work.
Yes, I agree that there are a million issues like this and we can't
mention them all explicitly. In this case, though, it's worth a
specific mention just because experience shows that many people wonder
about it and ask (presumably because the presence of lexical scoping
suggests other similarities with Scheme).
∂17-Jul-86 1239 NGALL@G.BBN.COM APPEND and NCONC
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 17 Jul 86 12:39:16 PDT
Date: 17 Jul 1986 15:37-EDT
Sender: NGALL@G.BBN.COM
Subject: APPEND and NCONC
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]17-Jul-86 15:37:50.NGALL>
The doc for APPEND should be clarified to warn the user that APPEND
can return a non-list, e.g.,
(append '() t) => t
Also, the doc for NCONC should be clarified so that NCONC behaves
analogously to APPEND when its last argument is an atom.
-- Nick
{Sorry if this is a repeat.}
∂17-Jul-86 1358 REM@IMSSS Expanding macros more than once?
Received: from IMSSS by SU-AI with PUP; 17-Jul-86 13:57 PDT
Date: 17 Jul 1986 1356-PDT
From: Rem@IMSSS
Subject: Expanding macros more than once?
To: COMMON-LISP@SU-AI
Perhaps the best course is to say "it is an error" to code a macro in
such a way that it has different semantics different times it is expanded.
Then implementors will be free to expand multiple times in interpretor
and just once in compiler, or whatever other strategy they prefer,
but writers of macros will have to carefully avoid writing number-of-expand
dependent macros. This seems a better tradeoff than requiring all
interpretors to expand macros just once. Further debate welcome...
-------
∂17-Jul-86 1900 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Tail Recursion in Common Lisp ???
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jul 86 19:00:28 PDT
Date: Thu, 17 Jul 1986 22:00 EDT
Message-ID: <STEVER.12223534508.BABYL@MIT-OZ>
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: "Bernard S. Greenberg" <BSG@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Tail Recursion in Common Lisp ???
In-reply-to: Msg of 17 Jul 1986 10:53-EDT from Bernard S. Greenberg <BSG at STONY-BROOK.SCRC.Symbolics.COM>
Date: Thursday, 17 July 1986 10:53-EDT
From: Bernard S. Greenberg <BSG at STONY-BROOK.SCRC.Symbolics.COM>
If the spec -allows- tail-recursion optimization, and "my"
implementation "supports" tail-recursion, then "I" can ... write a
"tail-recursive" program, which ... will blow the stack of most
certified implementations that do not "support" tail-recursion,
and is thus, subtly, not portable.
Which is why, even though tail recursion is an attribute of the
implementation, it might be nice for the standard to say something on
the issue (either a "yes, you can assume it" or "no, you can't.")
A lot of people, at least at MIT, are learning Lisp via SCHEME, so
they come out into the real world believing that tail recursion is a
safe way to do things.
Since I'm relatively new to the list, I'm not familiar with discussion
of iteration constructs at all. I sat down to write a quickie Common Lisp
program which used tail recursion, and was rather surprised when it
blew up. The last form in the body was an IF, in which both branches
called the toplevel function (I had hoped) tail-recursively.
Can this kind of iteration be \nicely/ expressed other ways?
Zetalisp's LOOP was able to give me what I wanted, expressed in a very
different way. But since it's not part of the standard (and I dislike
its non-LISPish syntax), I'd rather not use it.
A rough example of the kind of thing I was doing:
(defun remove (atom list)
(labels ((remove-1 (remaining result)
(cond ((endp remaining) result)
((eq (first remaining) atom)
(remove-1 (cdr remaining) result))
(t (remove-1 (cdr remaining)
(cons (first remaining)
result))))))
(nreverse (remove-1 list '()))))
Thanks!
Stever
∂17-Jul-86 1939 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Tail Recursion in Common Lisp ???
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 17 Jul 86 19:38:54 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 44661; Thu 17-Jul-86 22:38:24 EDT
Date: Thu, 17 Jul 86 22:38 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Tail Recursion in Common Lisp ???
To: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <STEVER.12223534508.BABYL@MIT-OZ>
Message-ID: <860717223819.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 17 Jul 1986 22:00 EDT
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Date: Thursday, 17 July 1986 10:53-EDT
From: Bernard S. Greenberg <BSG at STONY-BROOK.SCRC.Symbolics.COM>
If the spec -allows- tail-recursion optimization, and "my"
implementation "supports" tail-recursion, then "I" can ... write a
"tail-recursive" program, which ... will blow the stack of most
certified implementations that do not "support" tail-recursion,
and is thus, subtly, not portable.
Which is why, even though tail recursion is an attribute of the
implementation, it might be nice for the standard to say something on
the issue (either a "yes, you can assume it" or "no, you can't.")
A lot of people, at least at MIT, are learning Lisp via SCHEME, so
they come out into the real world believing that tail recursion is a
safe way to do things.
There are some implementations that will drop out if they are forced to
implement tail recursion. The standard argument revolves around
programming environments and debugger information.
Since I'm relatively new to the list, I'm not familiar with discussion
of iteration constructs at all. I sat down to write a quickie Common Lisp
program which used tail recursion, and was rather surprised when it
blew up. The last form in the body was an IF, in which both branches
called the toplevel function (I had hoped) tail-recursively.
Can this kind of iteration be \nicely/ expressed other ways?
Zetalisp's LOOP was able to give me what I wanted, expressed in a very
different way. But since it's not part of the standard (and I dislike
its non-LISPish syntax), I'd rather not use it.
A rough example of the kind of thing I was doing:
(defun remove (atom list)
(labels ((remove-1 (remaining result)
(cond ((endp remaining) result)
((eq (first remaining) atom)
(remove-1 (cdr remaining) result))
(t (remove-1 (cdr remaining)
(cons (first remaining)
result))))))
(nreverse (remove-1 list '()))))
Try
(defun remove (atom list)
(do ((rev-answer nil (if (eql (first remaining) atom)
rev-answer
(cons (first remaining) rev-answer)))
(remaining list (cdr remaining)))
((endp remaining) (nreverse rev-answer))))
Somebody made the claim the other day, I think on this list, that if you
had tail recursion you can do away with the "syntactic sugar" of
iteration constructs. I'll claim that is somewhat bogus. The iteration
constructs express an idea. They express iteration. Syntactic sugar
embodies ideas and provides abstractions. Also, the iteration
constructs can easily macroexpand into tail recursive calls if that's
the way you want to implement them.
∂18-Jul-86 0903 cscott@bfly-vax.bbn.com Re: Tail Recursion in Common Lisp ???
Received: from [128.89.0.157] by SU-AI.ARPA with TCP; 18 Jul 86 09:03:08 PDT
To: "David C. Plummer" <DCP@scrc-quabbin.ARPA>
cc: Common-Lisp@su-ai.ARPA
Subject: Re: Tail Recursion in Common Lisp ???
In-reply-to: Your message of Thu, 17 Jul 86 22:38 EDT.
<860717223819.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 18 Jul 86 11:55:17 EDT (Fri)
From: cscott@bfly-vax.bbn.com
I hope this issue has not been rehashed too many times -- I have not
been reading this list for long.
Scheme at MIT left out iterative constructs as a pedagogical
exercise, both to show that it was practical and to force
students (who are usually familiar with iterative constructs)
to think recursively. Syntactic sugar for iteration (e.g. DO)
appears in the new Scheme standard, and is acknowledged by most
Scheme people to be a useful way of thinking about many problems.
An implementation of Common Lisp that does not do tail recursion is
just a bad implementation. Specifications of resource optimizations
do not belong in the language spec; it is up to the buyers/users to be
aware of the limitations of an implementation. Buying a Common Lisp
which lacks tail recursion is like buying a car with a 2-pint gas
tank -- it'll get you moving, but not too far.
There is a legitimate worry here. If programmers believe (as ZetaLISP
programmers do) that recursion is a bad thing because of resource
constraints, they won't use one of the two most useful styles of
programming in Lisp. Instead of putting a requirement in the
language, the common wisdom should be that a Common Lisp without tail
recursion (or a compiler, which should go much further in static
analysis of resource usage) is not to be taken seriously. Then we can
all assume it, much as C programmers assume at least 2K words of
stack. Otherwise portable code will avoid it, and all Common Lisp
programmers will be the poorer.
∂18-Jul-86 0944 FAHLMAN@C.CS.CMU.EDU Tail Recursion in Common Lisp ???
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jul 86 09:44:19 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 18 Jul 86 12:44:32-EDT
Date: Fri, 18 Jul 1986 12:44 EDT
Message-ID: <FAHLMAN.12223695429.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: Tail Recursion in Common Lisp ???
In-reply-to: Msg of 18 Jul 1986 11:55-EDT from cscott at bfly-vax.bbn.com
It is my belief, based on what I know of the constraints various groups
feel they are working under, that there is no chance in hell that
required tail-recusrion removal will be added to Common Lisp in the near
future. There's just no point in discussing this further. If you want
a guarantee that tail-recursion will be handled well, use Scheme or that
subset of Common Lisps that are able to support this; if you want a
guarantee that your code will be efficient in Common Lisp, use DO.
I believe that tail-recursion removal will be ALLOWED in the final spec,
though some groups read the current manual as requiring a full call,
even from a function to itself, in case someone has installed a new
definition for FOO in the middle of running FOO. We will discuss this
and, I hope, find a set of rules under which tail-recursion removal is
legal (but not required) unless the user has explicitly requested the
full call. We will of course try to clearly document exactly what is
allowed and what is required in this area, once this has been decided.
-- Scott
∂18-Jul-86 1029 bradley@Think.COM Re: Tail Recursion in Common Lisp ???
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 18 Jul 86 10:29:11 PDT
Received: by Godot.Think.COM; Fri, 18 Jul 86 13:28:33 edt
Message-Id: <8607181728.AA14934@Godot.Think.COM>
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Cc: Common-Lisp@su-ai.ARPA
Subject: Re: Tail Recursion in Common Lisp ???
In-Reply-To: Your message of Fri, 18 Jul 1986 12:44 EDT.
<FAHLMAN.12223695429.BABYL@C.CS.CMU.EDU>
Date: 18 Jul 86 13:28:27 EDT (Fri)
From: Bradley C. Kuszmaul <bradley@Think.COM>
Perhaps this has been mentioned before, but one way to think about
tail recursion which allows the right thing to happen if the user
modifies the definition of the function in the middle of running it is
to do as follows: Do the tail recursion by "goto"'ing indirectly
through the symbol's function cell (rather than by "goto"'ing directly
to the location where the code happens to be). (Of course, the "goto"
would reclaim the stack space of the current function call before allocating
the stack space for the recursive call.)
This allows the efficiency (mod one indirect pointer chase) of the
classical tail recursion (i.e. it does not eat up stack), with the program
illness of common-lisp (i.e. the semantics are preserved for dynamic
redefinition of functions)
Such a mechanism does screw up some debuggers, but we could argue that
* Implementors who want good debuggers should not do tail recursion, or
* Implementors should only do tail recursion if some appropriate declaration
is made.
Thus, there may be programming environment reasons (the debugger) for not
doing tail recursion, but it is possible to efficiently support tail recursion
even in the face of dynamic redefinition of function names.
In fact, this approach allows all of the "tail calls" to be optimized
by using the same "goto" mechanism, so mutually recursive functions
which are defined and compiled separately could win.
(One could even get rid of the extra pointer chase in the truly
recursive case by stating that if an INLINE declaration is made for
the function, then dynamic redefinition of the function is not allowed
and a direct goto could be used.)
-Brad
∂18-Jul-86 1058 cscott@bfly-vax.bbn.com Re: Tail Recursion in Common Lisp ???
Received: from [128.89.0.157] by SU-AI.ARPA with TCP; 18 Jul 86 10:58:08 PDT
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
cc: Common-Lisp@su-ai.ARPA, cscott@bfly-vax.bbn.com
Subject: Re: Tail Recursion in Common Lisp ???
In-reply-to: Your message of Fri, 18 Jul 1986 12:44 EDT.
<FAHLMAN.12223695429.BABYL@C.CS.CMU.EDU>
Date: 18 Jul 86 13:47:56 EDT (Fri)
From: cscott@bfly-vax.bbn.com
Naturally tail-recursion removal should not be allowed where it
would change the semantics! On a multiprocessor, for example,
if the semantics allow redefinition of a fun to affect a currently-running
instance, then naturally there would have to be a check for such
redefinition at the required point (presumably the application).
Ditto if there is a redefinition of the fun in the body of the fun.
∂18-Jul-86 1102 Masinter.pa@Xerox.COM Re: Tail Recursion in Common Lisp ???
Received: from XEROX.COM by SU-AI.ARPA with TCP; 18 Jul 86 11:01:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 18 JUL 86 11:02:04 PDT
Date: 18 Jul 86 11:01 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Tail Recursion in Common Lisp ???
In-reply-to: ...various messages ...
To: Common-Lisp@su-ai.ARPA
Message-ID: <860718-110204-6950@Xerox>
Can we keep the discussion of tail recursion down to contributions that
don't say some variation of the following:
tail recursers: "its elegant & I learned about it in my scheme class &
people who expect it will be unhappy"
tail pushers: "when you're debugging its nice to see how you got there,
and besides its hard to implement"
message recursers: "Can we keep the discussion of tail recursion down to
contributions that don't say some variation ...."
(Sorry:-)
Larry
∂18-Jul-86 1343 RICE@SUMEX-AIM.ARPA Tail Recursion.
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 18 Jul 86 13:42:27 PDT
Date: Fri 18 Jul 86 13:25:11-PDT
From: James Rice <Rice@SUMEX-AIM.ARPA>
Subject: Tail Recursion.
To: Common-Lisp@SU-AI.ARPA
Message-ID: <12223735614.56.RICE@SUMEX-AIM.ARPA>
Given that it seems most unlikely that CL implementations will be
required to support tail recursion optimisation, it also seems likely
that we will be stuck with having to decorate function definitions,
which we want to be compiled tail recursively if possible.
Can I make a plea that this decoration, presumably some form of
declaration, should a) be part of the standard, requiring and b) NOT
be linked to such things as the Saftey switch, as it is in at least
one implementation. Tail recursion optimisation is something quite
orthogonal to generated code Safety.
Perhaps
(Declare (Optimize (Tail-Recursion)))
would be ok. I feel strongly that using such things as InLine
NotInLine to control such things, as was suggested a while back would
be most unclear.
Rice
-------
∂18-Jul-86 1645 REM@IMSSS No need to optimize tail recursion, use infinite virtual stack!
Received: from IMSSS by SU-AI with PUP; 18-Jul-86 16:45 PDT
Date: 18 Jul 1986 1410-PDT
From: Rem@IMSSS
Subject: No need to optimize tail recursion, use infinite virtual stack!
To: COMMON-LISP@SU-AI
If a finite segment of stack is in real memory, but upon overflowing the
stack the old part of it is swapped out to disk and the upper part in
memory bubbled down to make new room, an effectively infinite stack can
be emulated. With tail recursion emulating iteration, there is one big
sweep of gobbling up more and more virtual stack, followed by one
quick unwind of all that stack, thus very little thrashing, thus not
too inefficient. When bubbling the stack, stack frames have to be updated,
or else must reference virtual stack locations at the outset, but there
seem to be no major problems. Has any implementation of any LISP whatsoever
tried virtual infinite stacks?
-------
∂18-Jul-86 2039 willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Re: Tail Recursion in Common Lisp ???
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 18 Jul 86 20:39:37 PDT
Received: from tektronix by csnet-relay.csnet id am08979; 18 Jul 86 23:34 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA11810; Fri, 18 Jul 86 15:43:47 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA01359; Fri, 18 Jul 86 15:46:15 PDT
Message-Id: <8607182246.AA01359@tekchips.TEK>
To: common-lisp@SU-AI.ARPA
Subject: Re: Tail Recursion in Common Lisp ???
Date: 18 Jul 86 15:46:13 PDT (Fri)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
...does...Common Lisp require...tail recursion optimization ?
No. It has even been suggested that the current definition does not
allow tail-recursion optimization -- that's an issue we have to settle
soon, and I hope that we'll be able to work out a solution in which this
is allowed.
-- Scott
I recall a number of messages claiming that the current definition of
Common Lisp makes tail recursion optimization difficult, and I recall
that Kent Pitman pointed out that in (DEFUN FOO () (FOO)) the current
value of FOO must be fetched before the tail-recursive call is performed
(though this should have nothing to do with tail recursion optimization).
I don't recall any suggestion that the current definition of Common Lisp
does not allow tail-recursion optimization. How could a language
definition possibly disallow it?
-- Will Clinger
∂18-Jul-86 2129 FAHLMAN@C.CS.CMU.EDU Tail Recursion in Common Lisp ???
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jul 86 21:29:36 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 19 Jul 86 00:29:25-EDT
Date: Sat, 19 Jul 1986 00:29 EDT
Message-ID: <FAHLMAN.12223823751.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Tail Recursion in Common Lisp ???
In-reply-to: Msg of 18 Jul 1986 18:46-EDT from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA
I don't recall any suggestion that the current definition of Common Lisp
does not allow tail-recursion optimization. How could a language
definition possibly disallow it?
OK, it was suggested that it was illegal to optimize a function that
calls itself tail-recursively into a simple iteration that just jumps
back to the start of the current function without checking for
redefinition of the function in the meantime. The discussion was not
about the legality of doing the jump instead of a full recursive call,
but about whether the check was required.
-- Scott
∂18-Jul-86 2216 HELLER%cs.umass.edu@CSNET-RELAY.ARPA Question about the function DOCUMENTATION
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 18 Jul 86 22:16:03 PDT
Received: from umass-cs by csnet-relay.csnet id aq09670; 19 Jul 86 1:14 EDT
Date: Fri, 18 Jul 86 10:46 EST
From: Stride 440 User <HELLER%cs.umass.edu@CSNET-RELAY.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: Question about the function DOCUMENTATION
I have some questions about what the DOCUMENTATION function should
do about "exotic" doc-types. Under VAXLISP (DEC's Common LISP for VMS) and
on the TI Explorers' LISP, documentation strings are stored on a property
list under a documentation property of the symbol (VAXLISP also has a text
library for system supplied symbols and uses a special keyword symbol to
flag the fact that the documentation is in the library). Neither system
cares what doc-type is. Thus doc-type can be any symbol. Under Lucid's
Common LISP for the SUN Workstation, only the five doc-types mentioned in
the Common LISP manual are allowed. Lucid's Common LISP uses a structure
with five hash tables to store the documentation strings. The manual lists
five documentation types (variable, function, structure, type and setf), but
does not say whether these are the only allowed types.
My question is:
Is it intended that only the five doc-types be allowed (in which
case Lucid's Common LISP is correct) or merely the these five types are
used by the standard DEFxxx special-forms/macros supplied by Common LISP and
that user packages can add new documentation types as desired (in which case
Lucid's Common LISP is wrong)?
Robert Heller
Heller@UMass-CS.CSNET
∂19-Jul-86 0909 FAHLMAN@C.CS.CMU.EDU Question about the function DOCUMENTATION
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jul 86 09:09:20 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 19 Jul 86 12:09:18-EDT
Date: Sat, 19 Jul 1986 12:09 EDT
Message-ID: <FAHLMAN.12223951166.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Stride 440 User <HELLER%cs.umass.edu@CSNET-RELAY.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Question about the function DOCUMENTATION
In-reply-to: Msg of 18 Jul 1986 11:46-EDT from Stride 440 User <HELLER%cs.umass.edu at CSNET-RELAY.ARPA>
By my reading of the manual, an implementation is only required to
support the five types of documentation specified. Allowing an
arbitrary symbol to be used as the type argument to
(SETF (DOCUMENTATION symbol doc-type)) is a nice extension, and most
implementations get this for free, but it is neither required nor
forbidden by anything currently in the manual. So both Lucid and DEC
are in compliance on this.
-- Scott
∂19-Jul-86 1428 NGALL@G.BBN.COM Re: DECLARE SPECIAL Considered Confusing
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 19 Jul 86 14:18:23 PDT
Date: 19 Jul 1986 17:17-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: DECLARE SPECIAL Considered Confusing
From: NGALL@G.BBN.COM
To: Pavel.pa@XEROX.COM
Cc: Moon@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]19-Jul-86 17:17:01.NGALL>
In-Reply-To: <860711-184339-1110@Xerox>
Date: 11 Jul 86 18:43 PDT
From: Pavel.pa@Xerox.COM
In this message I will give a complete description of my proposal for
declaration scoping. I won't attempt to argue for it on the basis of
``obviousness'' or clarity, though, because I think that there are
people who find each of the two ways of scoping special declarations
confusing. Rather, I like this way of doing things because it satisfies
an important (to me) consistency criterion: the scope of \any/
declaration coincides with a particular lexical identifier scope.
I don't think you mean 'any' here; I think you mean 'any declaration
that concerns the bindings of variables' (cf. pg. 154). You cannot
mean 'any' since in the example below
(let ((x 1))
(declare (inline foo))
(foo x))
the declaration does not 'coincide with a particular lexical
identifier scope.' A more extreme example is
(let (...)
(declare (optimize ...))
...)
in which the declaration does not refer to ANY named entity.
If we consider declarations that only concern the bindings of
variables, we see that CLtL already agrees with your consistency
criterion: "[Declarations] that concern variable bindings apply only
to the bindings made by the form at the head of whose body they
appear." (pg. 154) Thus by definition, the scope of the decl. is the
scope of the binding.
Thus in the following example of valid CL code
(let ((x (oddp x)))
(declare (type (member t nil) x))
...)
The declaration has no effect on the reference of x in
the init form.
Unfortunately, TYPE and IGNORE are the only decl specs that only
concern bindings. SPECIAL concerns bindings also, but it
also pervasively affects references (this is what you want changed).
And FTYPE and INLINE simply confuse me.
First of all, FTYPE is not explicitly stated to be a pervasive decl
spec, I believe this is an omission. Secondly, there is this
confusing sentence at the end of their descriptions:
"Note that the rules of lexical scoping are observed; if one of the
functions mentioned has a lexically apparent local definition (as made
by FLET or LABELS), then the declaration applies to that local
definition and not to the global definition."
This makes it sound like FTYPE and INLINE are like SPECIAL: they
concern bindings AND affect references (but not pervasively?).
For example,
(FLET ((zap (...)...(zap...)...))
(declare (inline zap))
...)
Is the call to zap in the local definition of zap affected by the
declaration? My reading of CLtL and commonsense make me answer no.
The call to zap is not a call to the local def. of zap, and according
to my reading of the sentence quoted above, the decl. only affects
references within the scope of the innermost binding of the name zap.
But this interpretation depends upon not interpreting 'pervasively' as
stated in CLtL. Is my interpretation correct?
If so, it seems to me that FLET and INLINE already work in an intuitive
manner. Consider the following example:
(FLET ((zap () (zoop)))
(declare (inline zoop))
...)
According to my reading of CLtL, the call to zoop IS affected by the
declaration. And this makes sense to me. I could not tell from
Pavel's proposal whether or not this would be true in his proposal.
I propose the following change to CLtL (which pretty much agrees with
both CLtL and Pavel):
For all decl specs that concern named entities (and this includes all CLtL
decl specs except OPTIMIZE (the DECLARATION decl spec doesn't really
matter)),
If the name mentioned in the decl spec of a declaration that appears
at the beginning of a form in whose 'head' the name is bound, then the
declaration affects that binding and all references within the
binding's scope.
Otherwise, if the name mentioned in the decl spec of a declaration
that appears at the beginning of a form is not the name of a binding
established by that form (this is just another way of stating what was
stated in the antecedent of the above sentence), then the declaration
does not affect any binding, but it affects all references in the
entire form (from the open parenthesis to the close).
In addition, the distinction between 'pervasive' and non-pervasive
declarations should be flushed. It is a bogus distinction.
Some examples should help clarify this:
(let ((y x))
(declare (type list x))
...x...)
Both references to x are affected. This would be a new (upward
compatible) feature (and a useful one I think). Note: Currently,
TYPE is said to 'affect' only bindings. This is bogus. It also
affects all references to the binding. This can be seen in many
compilers when one references the binding incorrectly, e.g.,
(let ((x 1))
(declare (type integer x))
(car x))
(let ((x x))
(declare (type list x))
...x...)
Only the second reference to x is affected (since the first reference
is not within the scope of the binding named by x. The binding of x
is also affected (i.e., type checking may be done at
binding/assignment time). This example is also valid for the SPECIAL
dec spec.
(let ((x 1))
(declare (type t x))
...
(let ()
(declare (type cons x))
(setf x (cons 1 2))
...x...))
The 'reference' to x in the SETF form is affected by the second
declaration only (as is the other reference).
(let ()
(declare (ignore x))
...x...)
The reference to x is affected (The compiler should issue a warning
that an ignored variable was referenced.). This kind of declaration
might be useful in code generated by a macro to cause a check that
user written code in the body does not reference certain 'reserved'
specials.
(FLET ((zap (...)...(zap...)...(zoop...)...))
(declare (function zap (...)...)
(function zoop (...)...))
...)
The call to zap is not affected, but the call to zoop is.
(LAMBDA (&optional (x x) (y (zap x)))
(declare (type list x)
(function zap...))
...)
Only the second ref. of x is affected. The call to zap if affected by
the FUNCTION decl spec.
Here comes the only new, incompatible (with some implementations:-)
behaviour:
(let ((x 'local))
(let ((x 'special)
(y x))
(declare (special x))
...))
The ref. to x is not affected by the declaration (x still refers
to the lexical binding.). This is different from current CLtL
semantics.
(let ((x 1))
(let ((y x))
(declare (special x))
...x...))
BOTH refs. to x ARE affected by the declaration. This is actually
consistent with current CLtL semantics.
Finally, decl specs that do not concern named entities (the only one
in CL is OPTIMIZE), always affect all subforms within the form in
which the decl spec is declared.
I believe this proposal is complete, consistent, and simple to apply.
Comments?
-- Nick
∂19-Jul-86 2058 DCP@QUABBIN.SCRC.Symbolics.COM get-setf-method takes optional environment argument
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 19 Jul 86 20:58:18 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 21732; Sat 19-Jul-86 23:55:51 EDT
Date: Sat, 19 Jul 86 23:57 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: get-setf-method takes optional environment argument
To: common-lisp@SU-AI.ARPA
Message-ID: <860719235739.4.DCP@FIREBIRD.SCRC.Symbolics.COM>
I think we all agree (at least we seemed to last September or so) that
get-setf-method needs to tkae an optional environment argument in order
to correctly expand things. For example
(defmacro foo (a b) `(aref ,a ,b))
(setf (ldb (byte 2 2) (foo (x) (y))) (z))
== (setf (ldb (byte 2 2) (aref (x) (y))) (z))
but, given the above defmacro is still the global definition
(macrolet ((foo (a b) `(aref ,a 2 ,b))) ; added a 2 in the middle
(setf (ldb (byte 2 2) (foo (x) (y))) (z)))
should be
== (setf (ldb (byte 2 2) (aref (x) 2 (y))) (z))
but given the descipiption in CLtL it has no way to see the macrolet'd
definition of FOO, and will therefore expand incorrectly.
Did we also decide DEFINE-SETF-METHOD needs to allow an &ENVIRONMENT
argument to be able to effect this?
xo
∂19-Jul-86 2132 RAM@C.CS.CMU.EDU get-setf-method takes optional environment argument
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jul 86 21:32:52 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sun 20 Jul 86 00:32:35-EDT
Date: Sun, 20 Jul 1986 00:32 EDT
Message-ID: <RAM.12224086467.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: get-setf-method takes optional environment argument
In-reply-to: Msg of 19 Jul 1986 23:57-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
Did we also decide DEFINE-SETF-METHOD needs to allow an &ENVIRONMENT
argument to be able to effect this?
DEFINE-SETF-METHOD has an &environment arg in Spice Lisp. I don't see
any other way for hairy setf methods to get the environment. I
believe that this particular issue was overlooked while the discussion
was going on.
Rob
∂20-Jul-86 1048 JAR@AI.AI.MIT.EDU No need to optimize tail recursion, use infinite virtual stack!
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 20 Jul 86 10:48:44 PDT
Date: Sun, 20 Jul 86 13:49:55 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: No need to optimize tail recursion, use infinite virtual stack!
To: common-lisp@SU-AI.ARPA
Message-ID: <[AI.AI.MIT.EDU].72977.860720.JAR>
[I wanted to send this only to REM, but I don't know his network address
-- MIT-AI's mailer doesn't know about host IMSSS.]
Date: 18 Jul 1986 1410-PDT
From: Rem at IMSSS
To: COMMON-LISP at SU-AI
Re: No need to optimize tail recursion, use infinite virtual stack!
If a finite segment of stack is in real memory, but upon overflowing the
stack the old part of it is swapped out to disk and the upper part in
memory bubbled down to make new room, an effectively infinite stack can
be emulated. With tail recursion emulating iteration, there is one big
sweep of gobbling up more and more virtual stack, followed by one
quick unwind of all that stack, thus very little thrashing, thus not
too inefficient. When bubbling the stack, stack frames have to be updated,
or else must reference virtual stack locations at the outset, but there
seem to be no major problems. Has any implementation of any LISP whatsoever
tried virtual infinite stacks?
You'd be limited by the amount of available backing store, which is
certainly not "effectively infinite," and could very easily be
inadequate. E.g. assuming, say, 16 bytes per iteration of a loop, and a
200-megabyte backing store for the stack, a loop could only iterate less
than 13 million times. More typically, a loop might take 64 bytes, and
the backing store would be 30 meg, and you'd be limited to 500,000
iterations.
NIL took this approach, but with the heap instead of with the stack
(i.e. it had no GC), and it worked much better than I would have
expected. But in general, far fewer things are allocated on the heap
than on the stack, so I don't think that virtual memory, without either
GC or early deletion, would work as well for a stack.
Jonathan
∂20-Jul-86 1103 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (setf (not x) y) => (setf x (not y))
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 20 Jul 86 11:03:05 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 45856; Sun 20-Jul-86 13:59:30 EDT
Date: Sun, 20 Jul 86 13:59 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: (setf (not x) y) => (setf x (not y))
To: common-lisp@SU-AI.ARPA
Message-ID: <860720135927.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
NOT is not one of the special things recognized by SETF (CLtL pg 95++).
One theory says that if Y is not NIL, then X must be NIL and the right
semantics hold, but if Y is NIL, X could be anything that is not NIL,
whereas (not Y) will be T. I claim this is OK, since NOT is for boolean
purposes.
Anybody could do this via the escape clause on page 97: "Any form for
which a defsetf or define-setf-method declaration has been made."
However, I believe the spirit of the escape clause is for user forms,
not CLtL supplied forms, such as NOT.
[Randomness notch goes up. I hope this doesn't detract from the above,
which I think is quite reasonable.]
In theory the same could be applied to ZEROP. That is,
(setf (zerop x) y) => (setf x (if y 0 -1))
This is on the grounds that zerop is trying to test for all bits off and
therefore the inverse is all bits one. This, of course, assumes two's
complement arithmetic. Section 12.7, page 220, assumes this for the
logical operations. Maybe the correct expression for "all bits off" is
(not (logtest x -1)), and many people are potentially misusing ZEROP?
(BTW, ZEROP isn't in the index.)
I'll stop the randomness at this point and not mention 1+. Please
consider the first two paragraphs seriously. We can consider the rest
seriously only if we adopt the convention for SETF of NOT.
∂20-Jul-86 1217 FAHLMAN@C.CS.CMU.EDU (setf (not x) y) => (setf x (not y))
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jul 86 12:17:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 20 Jul 86 15:16:57-EDT
Date: Sun, 20 Jul 1986 15:16 EDT
Message-ID: <FAHLMAN.12224247468.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: (setf (not x) y) => (setf x (not y))
OK, I considered those suggestions as seriously as I could, and to me
they look utterly worthless and needlessly confusing. Unless you can
demonstrate some good use for these constructs that could not be done
much perspicuously and clearly using existing mechanisms, I suggest we
drop this.
-- Scott
∂20-Jul-86 1248 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (setf (not x) y) => (setf x (not y))
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 20 Jul 86 12:48:01 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 45875; Sun 20-Jul-86 15:46:47 EDT
Date: Sun, 20 Jul 86 15:46 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: (setf (not x) y) => (setf x (not y))
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224247468.BABYL@C.CS.CMU.EDU>
Message-ID: <860720154642.7.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sun, 20 Jul 1986 15:16 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
OK, I considered those suggestions as seriously as I could, and to me
they look utterly worthless and needlessly confusing. Unless you can
demonstrate some good use for these constructs that could not be done
much perspicuously and clearly using existing mechanisms, I suggest we
drop this.
Some of this may be tainted by the Symbolics environment, which has
DEFSUBST, which can easily be done in CLtL using PROCLAIM using INLINE
(that's what it actually does), and that SETF "happens to know" that it
should expand inline forms. This makes life a LOT easier, and probably
isn't considered portable CL. Doing it with inline functions is
prefereable to macros, as we shall see. With that as background,
consider this
(defstruct direction
up-p
left-p
front-p)
There are at least two ways to express the inverses. One is to build
them into the defstruct, and the other is to write abstractions that use
the existing slots. If macros were used, we would get
(defmacro direction-down-p (dir) `(not (direction-up-p ,dir)))
If SETF of NOT were to be adopted, it would automatically be possible to
SETF DIRECTION-DOWN-P. As it is, I have to
(defsetf direction-down-p (dir) (down-p)
`(setf (direction-up-p ,dir) (not ,down-p)))
and I have to do that for all of the others.
The reason inline functions are preferable for the standard reason: you
can't funcall macros. Since our substs are effectively macros to the
compiler (with hair to preserve order of evaluation if necessary), SETF
sees them as valid things to macroexpand.
The language should let me easily capture a concept (DIRECTION-DOWN-P)
and shouldn't burden me with a lot of tedious "junk" (DEFSETF of same)
in order to make effective use of it.
∂20-Jul-86 1310 @UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA Re: (setf (not x) y) => (setf x (not y))
Received: from UR-ACORN.ARPA by SU-AI.ARPA with TCP; 20 Jul 86 13:09:43 PDT
Received: from UR-CASHEW.ARPA by UR-ACORN.ARPA via INTERNET with SMTP id 30776; 20 Jul 86 16:06:03-EDT
Date: Sun, 20 Jul 86 16:06 EDT
From: Brad Miller <miller@UR-ACORN.ARPA>
Subject: Re: (setf (not x) y) => (setf x (not y))
To: dcp@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
Fcc: ACORN:>miller>mail>mailout.file
Message-ID: <860720160619.7.MILLER@UR-CASHEW.ARPA>
Sorry, I must be dense. What does this buy us?
Brad Miller
∂20-Jul-86 1411 ALAN@AI.AI.MIT.EDU DECLARE SPECIAL Considered Confusing
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 20 Jul 86 14:10:44 PDT
Date: Sun, 20 Jul 86 17:11:53 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: DECLARE SPECIAL Considered Confusing
To: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of 19 Jul 1986 17:17-EDT from NGALL at G.BBN.COM
Message-ID: <[AI.AI.MIT.EDU].73028.860720.ALAN>
Nobody has yet pointed out that changing the rules for (DECLARE (SPECIAL
...)) to follow the scoping of the variables involved does make it harder
for people to write certain macros that bind variables. For example,
consider trying to write LET*; you have to grovel through the declarations
in the body in order to distribute the SPECIAL declarations properly.
The old rule (which I have always found appalling -- I'm not trying to
defend it) did have the advantage that you can always extract the
declarations from the body of a macro form and just wrap the entire
expansion in a LOCALLY.
If we really intend to open this whole can of worms, it might also be a
good idea for someone to remind us all of the arguments for the concept of
"pervasive declarations".
∂20-Jul-86 1553 NGALL@G.BBN.COM Re: DECLARE SPECIAL Considered Confusing
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 20 Jul 86 15:53:12 PDT
Date: 20 Jul 1986 18:52-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: DECLARE SPECIAL Considered Confusing
From: NGALL@G.BBN.COM
To: ALAN@AI.AI.MIT.EDU
Cc: Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]20-Jul-86 18:52:13.NGALL>
In-Reply-To: <[AI.AI.MIT.EDU].73028.860720.ALAN>
Date: Sun, 20 Jul 86 17:11:53 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: DECLARE SPECIAL Considered Confusing
In-Reply-To: Msg of 19 Jul 1986 17:17-EDT from NGALL at G.BBN.COM
Message-ID: <[AI.AI.MIT.EDU].73028.860720.ALAN>
Nobody has yet pointed out that changing the rules for (DECLARE (SPECIAL
...)) to follow the scoping of the variables involved does make it harder
for people to write certain macros that bind variables. For example,
consider trying to write LET*; you have to grovel through the declarations
in the body in order to distribute the SPECIAL declarations properly.
The old rule (which I have always found appalling -- I'm not trying to
defend it) did have the advantage that you can always extract the
declarations from the body of a macro form and just wrap the entire
expansion in a LOCALLY.
I don't think the old rule did make
(LET* (...) (declare ...) ...) equivalent to
(locally (declare ...) {some expansion for LET*})
For example,
(let* ((x 1) (y (1+ x))) (declare (special x)) ...)
is not equivalent to
(locally (declare (special x))
(let ((x 1))
(let ((y (1+ x)))
...)
Since the declaration only affects the reference to x in (1+ x); the
outer LET incorrectly binds the lexical variable x.
The use of LOCALLY as you suggest, only works for pervasive
declarations, and the only purely pervasive declaration in CLtL is
OPTIMIZE.
As I said in my previous letter, I don't think FTYPE or INLINE are
purely pervasive. E.g.,
(flet ((foo (...) ...(foo...)...))
(declare (ftype (function...) foo))
(foo...)
...)
is not equivalent to
(locally (declare (ftype (function...) foo))
(flet ((foo (...) ...(foo...)...))
(foo...)
...))
since the declaration in the first form would affect only the second
call to foo and the decl. in the second form would affect only the
first call to foo.
If we really intend to open this whole can of worms, it might also be a
good idea for someone to remind us all of the arguments for the concept of
"pervasive declarations".
--------------------
I think the can is already open in the case of FTYPE and INLINE, since
CLtL is certainly muddled about whether they are simply pervasive
declarations or declarations that concern bindings and only the
references within the scope of the those bindings.
-- Nick
∂20-Jul-86 2134 FAHLMAN@C.CS.CMU.EDU Proposals
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jul 86 21:34:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 21 Jul 86 00:35:02-EDT
Date: Mon, 21 Jul 1986 00:35 EDT
Message-ID: <FAHLMAN.12224349069.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposals
Proposals 1 - 4 are now in the hands of the technical committee. We are
trying to work out a schedule for making decisions on these things. All
I can say right now is that we'll move on these as quickly as we can.
Next, I think we want to continue the discussion of Pavel's proposed
changes to declaration scope. I'll send out a message soon clarifying
what I think the proposal currently is. Most people who have expressed
opinions so far so far seem to favor the proposal on its merits, and
several have said that they hate the existing rules. The key question
now is whether anyone opposes this change, either on its merits or
because it would be too hard for them to implement. (I don't think it
will break much existing user code, but I could be wrong.) Speak now if
you want to oppose this change. I said it would take near-unanimity to
make a change of this size, and that's what we've seen so far.
While we're considering this hard issue, I will send out a bunch of easy
(I hope) proposals culled from the list of issues Guy Steele passed out
at the Boston meeting last December. Most of these were discussed on
the mailing list before December, and we seemed to agree on them at the
time, so my expectation is that few of these issues will result in fresh
controversy. We'll see.
-- Scott
∂21-Jul-86 0832 HASSETT%sperry-csd.csnet@CSNET-RELAY.ARPA GC function
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 21 Jul 86 08:31:53 PDT
Received: from sperry-csd by csnet-relay.csnet id aa26692; 21 Jul 86 11:30 EDT
Date: Mon, 21 Jul 86 09:26 ???
From: Jim Hassett <HASSETT%sperry-csd.csnet@CSNET-RELAY.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: GC function
The discussion concerning (GC) suggests that a major use would be to
trigger garbage collection so that delays could be avoided during some
subsequent processing, such as benchmarks or real-time operations. It
seems a bit devious to invoke garbage collection for the purpose of
preventing it, so perhaps a more direct approach to this application could
be used:
without-gc-delay form [Macro]
Evaluates form and returns what form returns, but prevents (as far as
is reasonable for the implementation) delays due to garbage collection.
It could be left up to the implementation to decide whether garbage collection
should be done before evaluating the form. Obviously, it is possible that
some forms which could otherwise be handled might exhaust available memory
when processed in this manner, unless the implementation can provide for
doing garbage collection if it can be seen to be necessary.
Does this make sense over a reasonably broad range of implementations?
Is it sufficiently useful to be included in the language?
- Jim Hassett
∂21-Jul-86 1104 greek%bach.decnet@hudson.dec.com A Bit More on Lambda-List Parsing
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Jul 86 11:03:59 PDT
Date: 21 Jul 86 14:04:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: A Bit More on Lambda-List Parsing
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
We've been off the network for a while, so I couldn't get in my two
cents on the issue of lambda lists and their parsing/representation.
If it's officially too late to comment, I apologize.
Why not define a function called PARSE-LAMBDA-LIST which takes
a lambda list and some information about what is allowed in it?
This function would parse the lambda list and return a structure (!).
This structure would contain all of the detailed information about
the lambda list, what was in it, whether &ALLOW-OTHER-KEYS was there,
blah, blah, blah.
There would also be a function that returned the structure describing
the lambda list for a given function (or macro, why not?). We could
design the structure so that each slot could either contain the
appropriate information or a value meaning "I don't know". In this
way, implementations which don't remember certain information
could indicate this.
- Paul
------
∂21-Jul-86 1125 greek%bach.decnet@hudson.dec.com Scope of Declarations.
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Jul 86 11:24:57 PDT
Date: 21 Jul 86 14:14:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Scope of Declarations.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
We've been off the network for a while, so I just got a chance to
read Pavel's proposal and the responses. I'd like to give a cheer
for this proposal, which simplifies declarations and removes some
of the bogusities of the current description. I have not thought
carefully about any new problems it might create.
Now, at the risk of hairing it up again, let me ask what people
think about declarations which do not pertain to a name being
bound in the current contour. In particular:
(LET ((X 1))
(DECLARE (FIXNUM Y))
...
(LOCALLY (DECLARE (FIXNUM Y))
...)
These are certainly powerful in many different situations. Is the
extra complexity worth it?
- Paul
------
∂21-Jul-86 1147 gls@Think.COM DESCRIBE-ARGUMENTS; or, special variables considered disgusting
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 21 Jul 86 11:44:51 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 14:45:00 edt
Date: Mon, 21 Jul 86 14:45 EDT
From: Guy Steele <gls@Think.COM>
Subject: DESCRIBE-ARGUMENTS; or, special variables considered disgusting
To: common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <8607151422.AA01086@Zarathustra.Think.COM>
Message-Id: <860721144545.8.GLS@BOETHIUS.THINK.COM>
Date: Tue, 15 Jul 86 10:20 EST
From: mike%gold-hill-acorn@mit-live-oak.ARPA
...
Info is also lost if it is a string. Package qualifiers are needed to
tell which variables are being bound if any of the symbols in the arglist
are specvars.
Arrgghhh. Letting any binding construct bind special variables
was a BIG mistake. Should have had a SPECLET construct and nothing
else.
Anyway, now that we are stuck with it, how about
FUNCTION-PARAMETER-NAMES has a symbol in the result if it is special and
a string if it is not?
(IN-PACKAGE 'YUK)
(DEFUN FOO (A B &REST C) (DECLARE (SPECIAL A C)) ...)
(IN-PACKAGE 'USER)
(FUNCTION-PARAMETER-NAMES 'YUK:FOO) => (YUK:A "B" &REST YUK:C)
That will show them! (Seriously, is specbinding any business of the
caller of FUNCTION-PARAMETER-NAMES?)
--Guy
∂21-Jul-86 1147 greek%bach.decnet@hudson.dec.com Declarations
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Jul 86 11:45:28 PDT
Date: 21 Jul 86 14:34:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Declarations
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I hadn't read Nick's clarification to Pavel's proposal before I sent
out my last message. Nick's clarification looks quite good.
A question: Why did you choose to say that declarations pertaining
to names that are not bound in the current contour affects references
in the entire form? Why not just in the body of the form?
I'm not sure I know which is better, I'm just wondering how you
decided.
- Paul
------
∂21-Jul-86 1201 gls@Think.COM Re: exit-to-system
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 21 Jul 86 12:01:00 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 15:00:56 edt
Date: Mon, 21 Jul 86 15:01 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: exit-to-system
To: common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860715120338.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <860721150138.9.GLS@BOETHIUS.THINK.COM>
Date: Tue, 15 Jul 86 12:03 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
...
I feel the same way about the BYE function. Common Lisp would need a
concept of "returning to the operating system" or something like that.
Some implementations do not have any such thing. It is out of the scope
of Common Lisp.
The only way I can imagine that such functions would be acceptable would
be if their definition said something like "In some implementations,
this function is allowed to do absolutely nothing". They would
therefore have to be considered part of a "user interface" rather than
part of the language, since no portable program could sensibly call
them. I think we should try to confine ourselves to the language
business. We have more than enough work ahead of us in that department!
Well, we do have ED, which is clearly a user-interface thing.
Here is a stab at defining QUIT:
QUIT [Function]
This function is intended to terminate the running Lisp system in some
appropriate manner. In some implementations or under some circumstances
the Lisp system and all data contained within it may be destroyed, more
or less irretrievably, in which case the user might be left in
communication with the ``operating system'' or ``command shell,'' or
might be ``logged out.'' In other implementations or under other
circumstances this function might do nothing, in which case the call to
QUIT returns NIL (to indicate that the call ``failed'').
←←←
/ \ This was a serious attempt. I happened to think that QUIT
| / | is a reasonable thing to standardize, but I find it very
| :/) | difficult to come up with a definition that is portable
| / | without seeming tongue-in-cheek.
\←←←/
--Guy
∂21-Jul-86 1301 ALAN@AI.AI.MIT.EDU DECLARE SPECIAL Considered Confusing
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 13:01:18 PDT
Date: Mon, 21 Jul 86 16:02:37 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: DECLARE SPECIAL Considered Confusing
To: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of 20 Jul 1986 18:52-EDT from NGALL at G.BBN.COM
Message-ID: <[AI.AI.MIT.EDU].73400.860721.ALAN>
Date: 20 Jul 1986 18:52-EDT
From: NGALL at G.BBN.COM
Date: Sun, 20 Jul 86 17:11:53 EDT
From: Alan Bawden <ALAN at AI>
The old rule ... did have the advantage that you can always extract
the declarations from the body of a macro form and just wrap the
entire expansion in a LOCALLY.
(let* ((x 1) (y (1+ x))) (declare (special x)) ...)
is not equivalent to
(locally (declare (special x))
(let ((x 1))
(let ((y (1+ x)))
...)
You're quite right. I had always assumed that the ability to extract
declarations like this was the reason we adopted the rule in the first
place (making both macros and documentation easier to write), but I was
certainly mistaken.
Actually, the more I think about this as a simplification, the more I like
it. So here is a counter-proposal for rationalizing the semantics of
declarations:
1. All declarations are completely pervasive. That is, if you write
(locally (declare (special foo)) ...)
then every occurance of FOO within the body is taken to be a special
reference or a special binding. The only way to escape from the effects of
a declaration within the body, is to explicitly shadow the declaration with
another. This applies to -all- declarations: FTYPE, INLINE, etc.
2. Declarations that occur in the bodies of special forms (DEFUN, LET, DO,
etc.), and in LAMBDA expressions, are taken to mean the same thing as if
the entire form was enclosed in a LOCALLY containing the same declarations.
So
(let ,pairs ,@dcls ,@body)
and
(locally ,@dcls (let ,pairs ,@body))
are completely equivalent.
(Since LAMBDA expressions aren't forms, the equivalent using LOCALLY isn't
always completely straightforward to construct. For example, this case:
((lambda ,vars ,@dcls ,@body) ,@vals)
is equivalent to using LOCALLY as follows:
(funcall (locally ,@dcls (function (lambda ,vars ,@body))) ,@vals)
.)
Question: Why isn't LOCALLY just called PROGN?
∂21-Jul-86 1347 greek%bach.decnet@hudson.dec.com Bawden's Alternate Proposal
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Jul 86 13:47:02 PDT
Date: 21 Jul 86 16:34:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Bawden's Alternate Proposal
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Bawden's proposal would result in the following.
(FLET ((FOO (X) (FOO X X)))
(DECLARE (FUNCTION FOO (INTEGER) INTEGER))
... (FOO 5) ...)
The declaration for FOO would pertain to both the locally-defined
FOO and the outer FOO used in its body. That's two different FOOs,
and the declaration is going to be a lie for one or the other!
A single declaration should never be able to refer to two different
entities with the same name.
- Paul
------
∂21-Jul-86 1431 gls@Think.COM Tail Recursion in Common Lisp ???
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 21 Jul 86 14:31:35 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 17:31:41 edt
Date: Mon, 21 Jul 86 17:32 EDT
From: Guy Steele <gls@Think.COM>
Subject: Tail Recursion in Common Lisp ???
To: Fahlman@C.CS.CMU.EDU, Common-Lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <FAHLMAN.12223695429.BABYL@C.CS.CMU.EDU>
Message-Id: <860721173224.8.GLS@BOETHIUS.THINK.COM>
Date: Fri, 18 Jul 1986 12:44 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
It is my belief, based on what I know of the constraints various groups
feel they are working under, that there is no chance in hell that
required tail-recusrion removal will be added to Common Lisp in the near
future. There's just no point in discussing this further. If you want
a guarantee that tail-recursion will be handled well, use Scheme or that
subset of Common Lisps that are able to support this; if you want a
guarantee that your code will be efficient in Common Lisp, use DO.
I believe that tail-recursion removal will be ALLOWED in the final spec,
though some groups read the current manual as requiring a full call,
even from a function to itself, in case someone has installed a new
definition for FOO in the middle of running FOO. We will discuss this
and, I hope, find a set of rules under which tail-recursion removal is
legal (but not required) unless the user has explicitly requested the
full call. We will of course try to clearly document exactly what is
allowed and what is required in this area, once this has been decided.
-- Scott
I agree with Scott's sentiment: we just can't require it now. One minor
correction: the removal of tail recursion is not necessarily synonymous with
failing to examine the function cell at call time; that is, one might have
removal of tail recursion (stack doesn't grow when you do a tail-recursive
call) that is not implemented by a simple JUMP instruction back to the top of
the current procedure. Tail-recursion removal is more general than
self-recursion removal. For more flames, see my paper in Proc. ACM '77
National Conference.
--Guy
∂21-Jul-86 1432 cscott@bfly-vax.bbn.com exit-to-system
Received: from [128.89.0.157] by SU-AI.ARPA with TCP; 21 Jul 86 14:32:23 PDT
Date: Mon, 21 Jul 86 17:19:58 EDT
From: "Curtis A. Scott" <cscott@bfly-vax.bbn.com>
To: common-lisp@su-ai.arpa
cc: gls@aquinas.think.com, cscott%bfly-vax@bbn.com
Subject: exit-to-system
Now I know you don't think multiple threads of control are a good
thing, but QUIT has a fairly natural interpretation in the Multilisp-style
world. It might mean "This computation has done the side-effects it
needed to do, so abandon it". This implies a return to
the operating system (if there is one) if there are no other threads
of control (since the work done by the REP loop has been declared
finished), or to reclamation of the task resources if the system as a whole
still has a goal. This is also a natural interpretation on a multitasking
lisp machine. Thus the concept is clear and not particularly
machine-dependent.
--Curtis
∂21-Jul-86 1453 ALAN@AI.AI.MIT.EDU Bawden's Alternate Proposal
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 14:53:38 PDT
Date: Mon, 21 Jul 86 17:55:05 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Bawden's Alternate Proposal
To: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 21 Jul 86 16:34:00 EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Message-ID: <[AI.AI.MIT.EDU].73460.860721.ALAN>
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Bawden's proposal would result in the following.
(FLET ((FOO (X) (FOO X X)))
(DECLARE (FUNCTION FOO (INTEGER) INTEGER))
... (FOO 5) ...)
The declaration for FOO would pertain to both the locally-defined
FOO and the outer FOO used in its body.
This is correct. Since function names are lexically scoped, you can call
the inner function something other than FOO with only a minor change to
your program. Is this situation actually common in anyone's code?
∂21-Jul-86 1526 NGALL@G.BBN.COM Re: Declarations
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 21 Jul 86 15:26:03 PDT
Date: 21 Jul 1986 18:24-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Declarations
From: NGALL@G.BBN.COM
To: greek%bach.decnet@HUDSON.DEC.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]21-Jul-86 18:24:30.NGALL>
In-Reply-To: The message of 21 Jul 86 14:34:00 EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Date: 21 Jul 86 14:34:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
To: "common-lisp" <common-lisp@su-ai.ARPA>
Subject: Declarations
I hadn't read Nick's clarification to Pavel's proposal before I sent
out my last message. Nick's clarification looks quite good.
A question: Why did you choose to say that declarations pertaining
to names that are not bound in the current contour affects references
in the entire form? Why not just in the body of the form?
I felt that decls pertaining to names not bound in the current
contour were analogous to the optimize decl which never pertains to
names. If I have a tight loop that I want to go fast, I write
(do ((rest list (rest rest)))
((endp rest...)
(declare (optimize (speed 3) (safety 0)))
...)
And I expect the optimize to affect the step forms and the end
test in addition to the actual body. If OPTIMIZE affected only the
'simple body', I'd have to write
(do ((rest list (locally (declare (optimize...)) (rest rest))))
((locally (declare (optimize...)) (endp rest))...)
(declare (optimize (speed 3) (safety 0)))
...)
Yech!
I think the same argument holds, for example, for INLINE. If I want
to open-code all calls to some accessor function in a do loop, where
some of the calls to the accessor function are in the step forms, I
don't want to use LOCALLY all over the place.
One can think up similar arguments for FLET, etc.
I'm not sure I know which is better, I'm just wondering how you
decided.
- Paul
------
--------------------
∂21-Jul-86 1647 masinter.PA@Xerox.COM (declare (type fixnum ---)) considered etc.
Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 Jul 86 16:47:08 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 21 JUL 86 16:47:28 PDT
From: masinter.PA@Xerox.COM
Date: 21 Jul 86 16:46:41 PDT
Subject: (declare (type fixnum ---)) considered etc.
To: common-lisp@su-ai.ARPA
Message-ID: <860721-164728-2170@Xerox>
I recently had the opportunity to port an application which had
(declare (type fixnum x y))
for some of the variables. Unfortunately, the variables could legally
exceed most-positive-fixnum in our implementation (where
most-positive-fixnum is 2↑16).
Currently the book does nothing to discourage such unportable
declarations. What would have been more reasonable would be to
(declare (type (signed-byte 32) x y))
if that was what had been meant....
I'd like to see the book (if not the spec) revised to explicitly
discourage using "fixnum" in declarations, if it isn't eliminated. Most
of the other type specifiers--including those with
implementation-dependent ranges such as short-float or
string-char--don't have the same problem because they correspond to
something real in the language.
∂21-Jul-86 1745 FAHLMAN@C.CS.CMU.EDU (declare (type fixnum ---)) considered etc.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Jul 86 17:45:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 21 Jul 86 20:45:44-EDT
Date: Mon, 21 Jul 1986 20:45 EDT
Message-ID: <FAHLMAN.12224569467.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: masinter.PA@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Subject: (declare (type fixnum ---)) considered etc.
In-reply-to: Msg of 21 Jul 1986 19:46-EDT from masinter.PA at Xerox.COM
We certainly can't remove the fixnum declaration, but we can warn
against this problem in the new spec. Whether anyone heeds the warning
is another matter.
-- Scott
∂21-Jul-86 1846 FAHLMAN@C.CS.CMU.EDU Some easy ones (?)
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Jul 86 18:46:31 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 21 Jul 86 21:46:51-EDT
Date: Mon, 21 Jul 1986 21:46 EDT
Message-ID: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Some easy ones (?)
What follows are ten proposals adapted from Steele's list of last
December. These have been discussed before, and I believe that they
should not stir up much new controversy. There are a lot of issues like
this, so I'm hoping that we can deal with these in batches, while
continuing to discuss more difficult issues like declaration scoping.
We shall see. Please read these over and indicate any problems you
discover, or whether they all look OK to you.
The plan is to discuss these things for a week (or more if complexities
arise), then to put the proposals forth in their final form for a last
round of comments, and finally to send the proposals to the technical
committee, who will make the final decisions.
This is something of an experiment. If we can't handle this many simple
things at once, we'll have to deal with issues in smaller batches, but
then it will take twice as long to settle these things.
-- Scott
---------------------------------------------------------------------------
Proposal #5: PARSE-BODY
Extension:
Add a new function (PARSE-BODY body environment documentation-allowed-p).
It pulls apart the body into three parts: a list of DECLARE forms, a
documentation string (or NIL if none), and the body proper. These are
returned in the order body, declarations, and doc-string as three
values. PARSE-BODY may perform macro-expansion (using the given
environment) in order to determine whether an initial macro-call expands
into a DECLARE form or documentation string.
---------------------------------------------------------------------------
Proposal #6: Parsing in &BODY
Change (could conceivably break existing code which destructures &body
arguments, but this should be rare as such destructuring is generally
too complex to do via the built in mmechanism):
Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
&body (body-var [declarations-var [doc-string-var]]). If only body-var
appears in parentheses, it means the same as a body-var with no
parentheses. Otherwise, it means to give the original body to
PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is
specified) and then bind the variables to the corresponding values
returned by PARSE-BODY. This is purely a syntactic convenience for the
user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then
call PARSE-BODY himself.
Note: This extension is proposed only for &BODY, not for &REST, so &BODY
will no longer be exactly equivalent to &REST in a DEFMACRO arglist.
[Note: KMP has suggested the syntax (...&body body-var decl-var doc-var).
This does not break any existing code and would allow default and
supplied-p values for the three variables. I (sef) don't think these are
important advantages, and I prefer the syntax proposed above, which is
less confusing to the eye -- my eye, ayway. The proposed format is the
one we discussed on the mailing list earlier and seemed to be favored by
most people.]
---------------------------------------------------------------------------
Proposal #7: TYPE-SPECIFIER-P
Proposed extension:
Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time.
---------------------------------------------------------------------------
Proposal #8: Clarifications to DEFCONSTANT
Clarifications:
Clarify that using DEFCONSTANT to redefine any constant described in the
Common Lisp specification is an error.
Clarify that if the user defines a constant, compiles code that refers
to that constant, and then redefines the constant, then behavior of the
compiled code may be unpredictable. It is an error to execute such
code.
Clarify that it is not an error to issue a second DEFCONSTANT command
for an existing constant iff the new value is EQL to the old one.
[That last clarification has not been discussed previously, as far as I
know, but seems to be needed for reloading certain compiled code files,
etc.]
---------------------------------------------------------------------------
Proposal #9: Variable Name Conflicts
Clarification:
Specify that it is an error for two parameters (including supplied-p and
&aux parameters) in the same lambda-list to have the same (EQL) name.
[As previous discussion brought out, we could instead allow this case
with the last-bound (rightmost) argument shadowing previous bindings in
the same arglist, but this is certainly bad style and interacts in nasty
ways with the proposed change to the scope of declarations.]
---------------------------------------------------------------------------
Proposal #10: Forms That Allow Declarations
Extension:
Permit declarations before the body of a LABELS, FLET, or MACROLET.
---------------------------------------------------------------------------
Proposal #11: Contents of Tagbody
Clarification:
Specify that constant forms such as strings may appear at top-level in a
tagbody, but that only symbols and integers are considered to be tags.
It is an error to use anything else as the destination tag for a GO.
[Several forms of this have been kicked around. This seems as good as
any. The original issue was whether you could put something like a
string at top-level and, if so, whether you could go to it.]
---------------------------------------------------------------------------
Proposal #12: Unique Names For Tags
Clarification:
Specify that it is an error for the same (EQL) tag to appear more than
once in the body of a TAGBODY. (However, a TAGBODY may have the same
tag as another TAGBODY in which it nests, in which case the tag in the
outer TAGBODY is shadowed, as already specified.)
---------------------------------------------------------------------------
Proposal #13: Structure Sharing in Arguments
Clarification:
Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
Similarly, a function that takes a &REST argument should not
destructively modify it because in some implementations its top-level
list structure might share with a list that the user gave as the last
argument to APPLY.
---------------------------------------------------------------------------
Proposal #14: THE and VALUES
Clarification:
Specify that in (THE (VALUES ...) form), the form may return more
values, but not fewer, than the number of types specified in the (VALUES
...) form, and that any extra values are of unrestricted type.
Also specify that (THE type form) where type is not (VALUES ...) is
equivalent to (THE (VALUES type) form).
---------------------------------------------------------------------------
∂21-Jul-86 1906 masinter.pa@Xerox.COM Re: (declare (type fixnum ---)) considered etc.
Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 Jul 86 19:06:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 86 19:06:46 PDT
Date: 21 Jul 86 19:02 PDT
From: masinter.pa@Xerox.COM
Subject: Re: (declare (type fixnum ---)) considered etc.
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Mon,
21 Jul 86 20:45 EDT
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@su-ai.ARPA
Message-ID: <860721-190646-2493@Xerox>
The fixnum declaration is one of the easiest things to remove.
a) Implementations that support (or need) fixnum declarations can add
them to their extension. This is clearly allowed by the spec, but it
becomes something that is an implementation's private extension rather
than part of the public, portable standard. The cost to implementors is
zero.
b) Users who have code that has fixnum declarations could add,
trivially, a
(deftype fixnum () ...)
c) The intent of fixnum declarations is reasonably supported by a much
more portable expression where the range of a variable is declared
explicitly rather than depending on implementation-dependent fixnum
ranges.
I don't know the source of the "certainly" in your message.
∂21-Jul-86 2211 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Declare Special
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 21 Jul 86 22:11:18 PDT
Received: from umass-cs by csnet-relay.csnet id ak02823; 22 Jul 86 1:10 EDT
Date: Mon, 21 Jul 86 10:33 EST
From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To: Common-Lisp@SU-AI.ARPA
Subject: Declare Special
I support cleaning up the semantics of declarations. I find myself
using *very* deffensive coding techniques instead of looking at
the manual every time I write a declaration.
I think the basic idea of putting the declaration inside the form it
is trying to affect is inherently un-lispish and will always be
confusing. I think that we should define a set of special forms
that syntactically enclose the body they apply to and supply the
needed functionality. Maybe in CL-2000 these can be made the standard.
Locally is a good start. I have a question about its semantics, though.
Consider:
(locally (declare (special foo))
(let ((foo <something>))
(print foo)))
I cannot figure out what this does from CLtL. Probably the binding is
not affected by locally, (even though the declaration is pervasive)
so in fact the binding *cannot* be referenced. The reference to foo
is (presumably) affected by a pervasive declaration, so this code
fragment does something unpredictable.
I think two additional special forms would be helpful. One would be
exactly like locally, except that it would pervasively affect bindings
as well as references to variables. In other words, this would be
a lexically scoped version of proclaim. (Perhaps call it proclaim-locally).
The last special form needed would supply the standard lexically
scoped declarations. Hopefully this is not too confusing.
The syntax would again be identical to locally, but the scope would
be everything through the scope of the next enclosing binding.
(For variable declarations of course.) For example:
(lexical-locally (declare (special x))
;; x special here.
(let ((x 3)) ;binds x specially.
;; x special here (and = 3)
(let ((x 4)) ;Binds x lexically.
....)))
People probably wouldn't want to use these at top-level, so there is
still a need for something like Pavel's suggestion. Elsewhere these
forms would usually be clearer.
∂21-Jul-86 2218 Masinter.pa@Xerox.COM Re: Some easy ones (?)
Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 Jul 86 22:17:55 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 86 22:15:20 PDT
Date: 21 Jul 86 22:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Some easy ones (?)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Mon,
21 Jul 86 21:46 EDT
To: common-lisp@SU-AI.ARPA
Message-ID: <860721-221520-2564@Xerox>
---------------------------------------------------------------------------
Proposal #6: Parsing in &BODY
I like (KMP's) &body body-var [declarations-var [doc-string-var]] over
Proposal #6.
1) KMP's is better style:
a) every other part of the argument list a list means (a
a-default-value) but Proposal#6 would mean (body declarations-var)
b) a list in &rest means to destructure; Proposal#6 would make a list
after &rest and &body mean very different things.
2) KMP's is simpler to describe in the manual. (No, "if you say (foo) it
means the same as foo")
3) upward compatible
--
For the many of the same reasons, I don't like allowing default or
supplied-p values for these; in addition, it is meaningless (what's the
difference between body not supplied and body = NIL?), and more
difficult to implement.
---------------------------------------------------------------------------
Proposal #7: TYPE-SPECIFIER-P
How about restricting it to symbols? Otherwise, there are imponderables,
e.g., if I say
(deftype frobnitz (&key a b) ...)
is (type-specifier-p '(frobnitz :a 3)) true and (type-specifier-p
'(frobnitz :c 3)) false?
Is (type-specifier-p '(array (3 3 #(a vector in the wrong place)))) true
or false?
At least with symbols there's some hope of a simple definition.
∂21-Jul-86 2355 Masinter.pa@Xerox.COM Re: exit-to-system
Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 Jul 86 23:55:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 86 23:55:45 PDT
Date: 21 Jul 86 23:55 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: exit-to-system
In-reply-to: Guy Steele <gls@Think.COM>'s message of Mon, 21 Jul 86
15:01 EDT
To: Common-lisp@su-ai.ARPA
Message-ID: <860721-235545-2606@Xerox>
A number of arguments seem to be of the form "Well, when I see the word
BYE I think it might mean turn off the power on my system..."
So lets go for a more specific name than QUIT (or EXIT) , which could
mean QUIT of any number of things (QUIT the process, QUIT the debugger
loop, QUIT this top-level loop, etc.) For example,
EXIT-LISP &optional forever [Function]
The exact behavior EXIT-LISP is, of course, implementation dependent.
Its purpose is to leave the running Lisp system. In Lisp systems that
run under an operating system with a command shell, this command returns
you to the operating system shell. The optional parameter "forever"
indicates whether there's any intention to return to this Lisp.
- - - - - - - - - - - - -
Interlisp in all of its implementations has had (LOGOUT) forever.
(LOGOUT) under Unix, VMS and Tops-20 meant "go to operating system". In
Interlisp-D, (LOGOUT) means "leave but save enough to let me come back"
and (LOGOUT T) means "leave without saving state".
A call to (LOGOUT) *can* return -- when you restart! It doesn't mean
that it "failed".
LOGOUT seems like a good model for what is wanted here. Users moving
from Interlisp-10 to Interlisp-D found it a natural analog, even though
what it did was very different.
∂22-Jul-86 0725 greek%bach.decnet@hudson.dec.com Declarations
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Jul 86 07:25:13 PDT
Date: 22 Jul 86 10:21:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Declarations
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
I think we should be very careful about declarations which can pertain
to more than one entity with the same name. Nick's proposal that all
declaration are pervasive brings out this problem in spades. I think it
is dangerous, since a declaration could easily tell a lie about one or
the other of the two entities.
- Paul
------
∂22-Jul-86 0850 @REAGAN.AI.MIT.EDU:MLY@AI.AI.MIT.EDU Proposal #5
Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 08:50:09 PDT
Received: from RICKY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 40336; Tue 22-Jul-86 11:52:25-EDT
Date: Tue, 22 Jul 86 11:51 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: Proposal #5
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
Message-ID: <860722115114.5.MLY@RICKY.AI.MIT.EDU>
Date: Mon, 21 Jul 1986 21:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Proposal #5: PARSE-BODY
Extension:
Add a new function (PARSE-BODY body environment documentation-allowed-p).
It pulls apart the body into three parts: a list of DECLARE forms, a
documentation string (or NIL if none), and the body proper. These are
returned in the order body, declarations, and doc-string as three
values. PARSE-BODY may perform macro-expansion (using the given
environment) in order to determine whether an initial macro-call expands
into a DECLARE form or documentation string.
There could be an &optional before then environment and doc-p args
(environment args are optional everywhere else: ie macroexpand and (proposed) eval.)
I have found it more convenient to return a list of declarations
(ie the "insides" of declare forms) rather than declare forms themselves.
That is, I would have
(parse-body '((declare (type atom x) (weird y)) (declare (special z y))))
return a decls value of ((atom x) (weird y) (special z y)).
This makes it easier for the caller to do assoc tests for certain kinds
of relevant declarations.
A sample call to this style of parse-body looks like:
(multiple-value-bind (body decls)
(parse-body body environment)
`#'(lambda ,arglist
(declare ,@decls)
(return-from ,block-name (progn . ,body))))
What ever happened to the (declare (documentation "foo")) proposal?
(The documentation declaration being equivalent to supplying a doc-string)
KMP (I believe) suggested this a long time ago and a lot of people seemed
to think that it was a good and necessary thing (some going as far as to
implement it)
If there were such a documentation declaration, a doc-string could just
be returned from PARSE-BODY as part of the declarations rather than as a
separate value. (The doc-string-valid-p arg is still needed, though)
∂22-Jul-86 0927 greek%bach.decnet@hudson.dec.com The Noncontroversial Ten Proposals
Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Jul 86 09:26:55 PDT
Date: 22 Jul 86 12:25:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: The Noncontroversial Ten Proposals
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
#5: PARSE-BODY
I think it should take another optional that says whether
declarations are allowed. This just makes it more general.
If it has to expand a macro to check for declarations and
finds that the expansion does NOT contain a declaration,
does it return the body with or without the first form
expanded?
How about returning two lists of declarations: those for
specials and all others? This could be used by the
interpreter. Is it worth the extra time?
I think the values should be returned in logical order:
declarations, doc-string, body.
What happened to our discussion of programs which modify constants?
I believe we agreed that was an error. Or was it too controversial?
How about a LET, FLET, or LABELS which defines the same name more
than once?
- Paul
------
∂22-Jul-86 0953 gls@Think.COM (setf (not x) y) => (setf x (not y))
Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 22 Jul 86 09:53:39 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Tue, 22 Jul 86 12:53:36 edt
Date: Tue, 22 Jul 86 12:54 EDT
From: Guy Steele <gls@Think.COM>
Subject: (setf (not x) y) => (setf x (not y))
To: DCP@QUABBIN.SCRC.Symbolics.COM, Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <860720154642.7.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-Id: <860722125418.3.GLS@BOETHIUS.THINK.COM>
Fine. I don't see any reason why a user shouldn't be allowed
to do a DEFSETF of NOT. I am not crazy about installing it as
a requirement in the language. Years ago I sent out examples
involving * and SQRT, looking something like this:
(setf (sqrt x) y) -> (setq x (* y y))
(setf (* x y) z) -> (setq x (/ z y))
(setf (* x x) z) -> (setq x (sqrt z))
We could do it, but it would be wrong.
--Guy
∂22-Jul-86 1024 RWK@YUKON.SCRC.Symbolics.COM (setf (not x) y) => (setf x (not y))
Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 22 Jul 86 10:24:39 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 60227; Tue 22-Jul-86 03:35:58 EDT
Date: Tue, 22 Jul 86 03:35 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: (setf (not x) y) => (setf x (not y))
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>,
common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224247468.BABYL@C.CS.CMU.EDU>
Message-ID: <860722033557.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Sun, 20 Jul 1986 15:16 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
OK, I considered those suggestions as seriously as I could, and to me
they look utterly worthless and needlessly confusing. Unless you can
demonstrate some good use for these constructs that could not be done
much perspicuously and clearly using existing mechanisms, I suggest we
drop this.
-- Scott
I have had "structure accessors" which worked by doing 1- on a stored
field that had to be stored 1-origin for some reason. After about
the third occurance of this, it was tempting to write a DEFSETF for
1- instead of for my accessors.
∂22-Jul-86 1034 Daniels.pa@Xerox.COM Re: Some easy ones (?)
Received: from XEROX.COM by SU-AI.ARPA with TCP; 22 Jul 86 10:33:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUL 86 10:25:42 PDT
Date: 22 Jul 86 10:24 PDT
From: Daniels.pa@Xerox.COM
Subject: Re: Some easy ones (?)
In-reply-to: Masinter.pa's message of 21 Jul 86 22:15 PDT
To: Masinter.pa@Xerox.COM
cc: common-lisp@SU-AI.ARPA
Message-ID: <860722-102542-2911@Xerox>
"Proposal #7: TYPE-SPECIFIER-P
How about restricting it to symbols? Otherwise, there are
imponderables..."
Seems like we would end up with the same situation as with SUBTYPEP -
there are three possible answers: yes, I'm sure; no, I'm sure; and no, I
can't tell.
-- Andy. --
∂22-Jul-86 1436 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Bawden's Alternate Proposal
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jul 86 14:36:13 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47447; Tue 22-Jul-86 15:35:36 EDT
Date: Tue, 22 Jul 86 15:36 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Bawden's Alternate Proposal
To: ALAN@MIT-AI.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <[AI.AI.MIT.EDU].73460.860721.ALAN>
Message-ID: <860722153640.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 21 Jul 86 17:55:05 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
This is correct. Since function names are lexically scoped, you can call
the inner function something other than FOO with only a minor change to
your program. Is this situation actually common in anyone's code?
It sounds like the basic idea of your proposal could be described as
follows: to keep everything simple and clear, get rid of the whole idea
of non-pervasive declarations. Everything is pervasive. Also,
everything applies (pervades) exactly around a specific lexical
enclosure, which is either the LOCALLY form, or the body of the special
form with a DECLARE in it. Why are non-pervasive declarations
flushable? Because the only reason for them was to affect one variable
named, say, "foo", without affecting another named "foo", and since
everything is lexically scoped, you can always just rename the other
"foo" to prevent the declaration from affecting it. That way, you don't
need the "fine control" provided by non-pervasive declarations.
I do like the idea of simplifying the rules as much as possible.
However, I am not completely happy with this as a philosophy for the
language. After all, we have a whole set of scoping rules designed to
deal with things like:
(let ((a ---))
...
(let ((a ---))
...))
While you're at it, you could simplify the scoping rules as well, by simply
not allowing such constructs; the user can always change the name of the
inner "a".
∂22-Jul-86 1437 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jul 86 14:37:00 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47557; Tue 22-Jul-86 16:53:01 EDT
Date: Tue, 22 Jul 86 16:53 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: (declare (type fixnum ---)) considered etc.
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, masinter.PA@XEROX.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224569467.BABYL@C.CS.CMU.EDU>
References: <860721-164728-2170@Xerox>,
<FAHLMAN.12224569467.BABYL@C.CS.CMU.EDU>
Message-ID: <860722165303.5.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon, 21 Jul 1986 20:45 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
We certainly can't remove the fixnum declaration,
Sorry, I don't see this as given. We can have a type of FIXNUM for
those that wanted to look, but we can make it illegal as a type
declaration because it produces non-portable code. I think a type
declaration of (signed-byte 32) is CORRECT for what the programmer meant
and therefore much more appropriate.
but we can warn against this problem in the new spec. Whether
anyone heeds the warning is another matter.
Languages should be useful and helpful for programmers (whether those
programmers are human or otherwise). Warnings should be heeded. One
could try arguing that if a function compiles with a warning, then the
compiler is at liberty to redefine the function as if it were written
(defun foo (&rest ignore)
(declare (ignore ignore))
(break))
and force the user to write code that at least passes the compiler's
tests.
∂22-Jul-86 1449 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Some easy ones (?) -- 107 lines of answer (!)
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jul 86 14:48:57 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47620; Tue 22-Jul-86 17:48:19 EDT
Date: Tue, 22 Jul 86 17:48 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Some easy ones (?) -- 107 lines of answer (!)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
Message-ID: <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
#5, parse-body, looks reasonable. Two comments: I don't think you need
a declarations-allowed-p argument on the grounds that the semantics of
PARSE-BODY implies declarations. What's the whole point? Along the
same lines you don't need documenation-allow-p. Don't you have to
return a list of doc strings? I don't know if the BODY returned should
contain the macroexpanded first form in case it wasn't a declare. Part
says yes, to avoid multiple expansion, part says no, on the grounds that
the compiler might have some knowledge of certain macros before they get
expanded. (E.g., it might arrange for the fail case of CHECK-TYPE to
branch to the end of the function to allow the normal case to do
sequential execution, but the expansion of CHECK-TYPE might destroy the
semantic meaning.
#6: This just seems to random to me. If you are really parsing a body,
you should be required to accept all three of new body, declarations and
documentation. I'm under the impression there are relatively few macros
that actually have to use PARSE-BODY (but those that do really need
it!), and therefore this syntax doesn't have high visibility. (P.s.,
(...&body body-var decl-var doc-var) will break a compile that isn't
prepared for it.)
#7: Why isn't (TYPE-SPECIFIER-P foo) == (typep foo 'type). In other
words, why not define a type named TYPE that fills this gap instead of a
new function.
#8, DEFCONSTANT: Yes. The last clarification is fine.
#9: Fine. There is a 35% reasonable counter example, but I've been
getting too random recently. Do you really want to say "is an error" or
"signals an error" when the compiler/interpreter tries to interpret such
code.
#10 declarations for LABELS, FLET: Yes. You may want to explicitly
state the a common such declaration is INLINE. I can't remember the
reason for MACROLET. Refresher?
#11 TAGBODY contents: Yes. The real issue is that tagbody tags must be
EQL, right? The restriction to symbols and integers as tags and strings
being part of the program is much less confusing.
#12 TAGBODY tag uniqueness: Yes. Consider changing "is an error" to
"signals an error". This is a compile-time issue, not a runtime issue,
so "signals an error" or "is an error and issues a warning" is more
appropriate.
#13 stack &REST lists: I don't think this is a clarification, it is a
changle. [It would be nice if there were page numbers to go with these
clarifications. This one is page 60 or so.] The clarification is not
strong enough. What is special with being called with APPLY? Doesn't
the same clarification allow stack-"consed" &REST args? That would
break some of the examples on page 64. If you really want to "clarify"
this, you must specify that it is an error to destructively modify the
&REST argument, and it is also an error to return it or store it in
stable storage. These restrictions have been complained about by
Symbolics customers for years. I think they are also confusing (which
is why we get complaints), in that the programmer has to be very keen on
when and how each list is being used. Consider this program
(defun foo (&rest b)
(bar b))
All of a sudden, FOO has to know that BAR's first argument will not be
destructively modified or stored in stable storage. This is highly
non-local to FOO. This is not an easy thing to solve /efficiently/.
Sure, the compiler can insert a (setq rest-arg (copy-list rest-arg)) all
the time, but it shouldn't have to.
In other words, I vote no.
#14 THE VALUES: Page 161? I can't remember the discussion, but this
seems pretty random. What I would prefer to see is a substantive change
here, which is along the lines of the following
(the type form)
arranges to return exactly one value and it is of type type. This is
similar to
(the (values type) form)
If you want all the values, and the first is of type type, you say
(the (values type . t) form)
If you want EXACTLY two values, you say
(the (values type1 type2) form)
The implementation is responsible for adding or removing values that
FORM returns to return exactly two. To do this today, one has to say
(multiple-value-bind (a b)
form
(values (the type1 a) (the type2 b)))
or
(multiple-value-bind (a b)
form
(the (values type1 type2) (values a b)))
Is this at all related to returning extra multiple values and using
multiple-value-call? I can imaging a smart compiler that would turn
(multiple-value-call
#'list
(the (values t t) (get-two-things))
(the (values t t t) (get-three-things)))
into efficient code that calls LIST of 5 arguments. As the language is
currently defined, the above could return a list of any number of
elements, from 0 to <value-of-some-constant-i-can't-remember>. What is
useful and what is really trying to be accomplished by this proposal?
=======
I think you better split things up. Maybe its just me being to
talkative and/or flaming. I'm quite fond of Common Lisp. Really! I
would like to see it do useful and reasonable things. If a change
doesn't look like it does both, then I question its motivation. #14 is
reasonable, but I don't see that it is useful, and I do see changes to
it that I think are also reasonable and are potentially useful for
programmers and implementations.
∂22-Jul-86 1505 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM GC function
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jul 86 15:05:11 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47635; Tue 22-Jul-86 17:59:31 EDT
Date: Tue, 22 Jul 86 17:59 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: GC function
To: Jim Hassett <HASSETT%sperry-csd.csnet@CSNET-RELAY.ARPA>,
common-lisp@SU-AI.ARPA
In-Reply-To: The message of 21 Jul 86 09:26 EDT from Jim Hassett <HASSETT%sperry-csd.csnet@CSNET-RELAY.ARPA>
Message-ID: <860722175932.7.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon, 21 Jul 86 09:26 ???
From: Jim Hassett <HASSETT%sperry-csd.csnet@CSNET-RELAY.ARPA>
Your date field ended in ???, which our mail header parser decided not
to parse.
The discussion concerning (GC) suggests that a major use would be to
trigger garbage collection so that delays could be avoided during some
subsequent processing, such as benchmarks or real-time operations. It
seems a bit devious to invoke garbage collection for the purpose of
preventing it, so perhaps a more direct approach to this application could
be used:
without-gc-delay form [Macro]
Evaluates form and returns what form returns, but prevents (as far as
is reasonable for the implementation) delays due to garbage collection.
It could be left up to the implementation to decide whether garbage collection
should be done before evaluating the form. Obviously, it is possible that
some forms which could otherwise be handled might exhaust available memory
when processed in this manner, unless the implementation can provide for
doing garbage collection if it can be seen to be necessary.
Does this make sense over a reasonably broad range of implementations?
I think so.
Is it sufficiently useful to be included in the language?
Quite possibly. This is the best thing I've seen from this discussion
so far. You also raise some of the right issues. As an example to some
of the things this would do in the Symbolics implementation, it would
prevent the GC from starting during execution, and cause "scavenging
during cons" to be turned off. As you say, the implementation may do
(or finish) a GC before entering the form. In copying garbage
collectors, you could have a "delay" by referencing an object in
oldspace and needing to transport it.
It may also be a reasonable restriction/warning that implementations
must be careful to avoid spending too much time within the form, since
it may inhibit all GC activity, and you could therefore run out of room.
∂22-Jul-86 1532 DCP@STONY-BROOK.SCRC.Symbolics.COM (setf (not x) y) => (setf x (not y))
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Jul 86 15:30:48 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 62527; Tue 22-Jul-86 18:28:25 EDT
Date: Tue, 22 Jul 86 18:26 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: (setf (not x) y) => (setf x (not y))
To: Guy Steele <gls@Think.COM>, DCP@QUABBIN.SCRC.Symbolics.COM,
Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860722125418.3.GLS@BOETHIUS.THINK.COM>
Message-ID: <860722182636.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 22 Jul 86 12:54 EDT
From: Guy Steele <gls@Think.COM>
Fine. I don't see any reason why a user shouldn't be allowed
to do a DEFSETF of NOT. I am not crazy about installing it as
a requirement in the language. Years ago I sent out examples
involving * and SQRT, looking something like this:
(setf (sqrt x) y) -> (setq x (* y y))
(setf (* x y) z) -> (setq x (/ z y))
(setf (* x x) z) -> (setq x (sqrt z))
We could do it, but it would be wrong.
Some things are more wrong than others. Anyway, an argument against
telling the user to DEFSETF of NOT is that some systems may complain if
more than one use tries to do that, on the grounds that different users
are stepping on each other's toes. Symbolics is such an implementation.
I think SETF of NOT has a fairly concise semantic meaning and is
generally useful, and at least 90% correct, if not higher.
∂22-Jul-86 1539 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (setf (not x) y) => (setf x (not y))
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jul 86 15:38:30 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47682; Tue 22-Jul-86 18:30:39 EDT
Date: Tue, 22 Jul 86 18:30 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: (setf (not x) y) => (setf x (not y))
To: Guy Steele <gls@Think.COM>, DCP@QUABBIN.SCRC.Symbolics.COM,
Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860722125418.3.GLS@BOETHIUS.THINK.COM>
Supersedes: <860722182636.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860722183008.5.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 22 Jul 86 12:54 EDT
From: Guy Steele <gls@Think.COM>
Fine. I don't see any reason why a user shouldn't be allowed
to do a DEFSETF of NOT. I am not crazy about installing it as
a requirement in the language. Years ago I sent out examples
involving * and SQRT, looking something like this:
(setf (sqrt x) y) -> (setq x (* y y))
(setf (* x y) z) -> (setq x (/ z y))
(setf (* x x) z) -> (setq x (sqrt z))
We could do it, but it would be wrong.
Some things are more wrong than others. Anyway, an argument against
telling the user to DEFSETF of NOT is that some systems may complain if
more than one use tries to do that, on the grounds that different users
are stepping on each other's toes. Symbolics is such an implementation.
I think SETF of NOT has a fairly concise semantic meaning and is
generally useful, and at least 90% correct, if not higher.
Maybe we should standardize
.defun sys:allow-redefinition function-spec &optional (type 'defun)
so that I can preface my implementation of DEFSETF of NOT with
(sys:allow-redefinition 'NOT 'DEFSETF)
? I'm quite serious about this (in addition to DEFSETF of NOT).
∂22-Jul-86 1548 bane.pa@Xerox.COM setf of nthcdr?
Received: from XEROX.COM by SU-AI.ARPA with TCP; 22 Jul 86 15:48:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUL 86 15:47:04 PDT
Date: 22 Jul 86 15:46 PDT
From: bane.pa@Xerox.COM
Subject: setf of nthcdr?
To: common-lisp@SU-AI.ARPA
Message-ID: <860722-154704-3382@Xerox>
On a mundane note, currently NTHCDR isn't required by CLtL to have a
SETF method. Unlike (setf (sqrt...)) and (setf (not...)), this one seems
to make sense and should be easy to agree on.
∂22-Jul-86 2112 NGALL@G.BBN.COM Re: Declarations
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 22 Jul 86 21:12:30 PDT
Date: 23 Jul 1986 00:10-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Declarations
From: NGALL@G.BBN.COM
To: greek%bach.decnet@HUDSON.DEC.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]23-Jul-86 00:10:56.NGALL>
In-Reply-To: The message of 22 Jul 86 10:21:00 EST from "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Date: 22 Jul 86 10:21:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
To: "common-lisp" <common-lisp@su-ai.ARPA>
Subject: Declarations
I think we should be very careful about declarations which can pertain
to more than one entity with the same name. Nick's proposal that all
declaration are pervasive brings out this problem in spades. I think it
is dangerous, since a declaration could easily tell a lie about one or
the other of the two entities.
- Paul
I think you mean Alan Bawden's proposal. I did not propose that all
declarations should be pervasive (only one's not associated with
bindings in the current contour). And I agree that such a simple rule
for decls is dangerous.
-- Nick
∂22-Jul-86 2135 NGALL@G.BBN.COM Re: Declare Special
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 22 Jul 86 21:35:24 PDT
Date: 23 Jul 1986 00:34-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Declare Special
From: NGALL@G.BBN.COM
To: ELIOT%cs.umass.edu@RELAY.CS.NET
Cc: Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]23-Jul-86 00:34:19.NGALL>
In-Reply-To: The message of Mon, 21 Jul 86 10:33 EST from ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
Date: Mon, 21 Jul 86 10:33 EST
From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To: Common-Lisp@SU-AI.ARPA
Subject: Declare Special
I think the basic idea of putting the declaration inside the form it
is trying to affect is inherently un-lispish and will always be
confusing. I think that we should define a set of special forms
that syntactically enclose the body they apply to and supply the
needed functionality. Maybe in CL-2000 these can be made the standard.
The best place to put a decl is adjacent to the entity it refers to (a
la Ada). I don't know of any language that puts declarations for
function parameters BEFORE the parameters (do you); those that don't
put them adjacent to the parameters (e.g., C) put them 'inside the
body'. I think that is a pretty good reason for CL to do the same.
Locally is a good start. I have a question about its semantics, though.
Consider:
(locally (declare (special foo))
(let ((foo <something>))
(print foo)))
I cannot figure out what this does from CLtL. Probably the binding is
not affected by locally, (even though the declaration is pervasive)
so in fact the binding *cannot* be referenced. The reference to foo
is (presumably) affected by a pervasive declaration, so this code
fragment does something unpredictable.
You figured it out. A good compiler will warn you that the lexical
variable foo is never referenced. The fragment's behavior is quite
predicatable: it will print the value of the special variable foo.
I think two additional special forms would be helpful. One would be
exactly like locally, except that it would pervasively affect bindings
as well as references to variables. In other words, this would be
a lexically scoped version of proclaim. (Perhaps call it proclaim-locally).
Could you give some examples of how proclaim-locally would be helpful?
It sounds relatively useless to me.
The last special form needed would supply the standard lexically
scoped declarations. Hopefully this is not too confusing.
The syntax would again be identical to locally, but the scope would
be everything through the scope of the next enclosing binding.
(For variable declarations of course.) For example:
(lexical-locally (declare (special x))
;; x special here.
(let ((x 3)) ;binds x specially.
;; x special here (and = 3)
(let ((x 4)) ;Binds x lexically.
....)))
All I can say is that I prefer my decls as close to their entities as
possible, and you are suggesting a syntax that would allow them to be
moved arbitrarily far away, and to affect unrelated references, i.e.,
what has the x outside the outer LET got to do with the x bound in the
outer LET? Why should they share a decl?
People probably wouldn't want to use these at top-level, so there is
still a need for something like Pavel's suggestion. Elsewhere these
forms would usually be clearer.
Having two different declaration styles is bound to be more confusing
than one.
-- Nick
∂22-Jul-86 2140 hpfclp!diamant@hplabs.HP.COM Structure sharing in arguments
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 22 Jul 86 21:39:51 PDT
Received: by hplabs.HP.COM ; Tue, 22 Jul 86 21:39:37 pdt
Date: Tue, 22 Jul 86 21:39:37 pdt
From: hpfclp!diamant@hplabs.HP.COM
To: common-lisp@su-ai.ARPA
Subject: Structure sharing in arguments
From: Scott Fahlman <fahlman@C.CS.CMU.EDU>
Subject: Some easy ones (?)
Proposal #13: Structure Sharing in Arguments
Clarification:
Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
Similarly, a function that takes a &REST argument should not
destructively modify it because in some implementations its top-level
list structure might share with a list that the user gave as the last
argument to APPLY.
I don't really care whether you add a restriction not to do destructive
operations on a &REST or &BODY argument, but it better be clear that the
list returned may not be something which will go away on exiting the function
(which could happen if the parameter list were stored on the stack and a
pointer to that list was returned -- apparently what Symbolics does).
Nothing currently in CLtL limits me from doing the following (nor should it):
(defun foo (&rest x) x)
About an earlier issue which I didn't have time to respond to when
it came up regarding the error level proposal: regardless of how the details
are worked out, I don't want the set of "must" reportable errors to be very
large. At least not at all levels of safety/speed. There should be an out
of at least one combination which allows very minimal error checking. If I
remember correctly from your proposal, you suggested that anything which
"signals an error" should be an always required reportable error. I wouldn't
mind having only one combination of safety/speed which would not require this,
but I would strongly object to having all these errors required to be
reportable no matter what optimizations are requested. Conventional
architecture implementations pay a substantial performance penalty for every
error check emitted in the final code.
John
∂22-Jul-86 2218 ALAN@AI.AI.MIT.EDU Bawden's Alternate Proposal
Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 22:18:36 PDT
Date: Wed, 23 Jul 86 01:20:16 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Bawden's Alternate Proposal
To: DLW@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of Tue 22 Jul 86 15:36 EDT from Daniel L. Weinreb <DLW at QUABBIN.SCRC.Symbolics.COM>
Message-ID: <[AI.AI.MIT.EDU].74164.860723.ALAN>
Date: Tue, 22 Jul 86 15:36 EDT
From: Daniel L. Weinreb <DLW at QUABBIN>
...
However, I am not completely happy with this as a philosophy for the
language. After all, we have a whole set of scoping rules designed to
deal with things like:
(let ((a ---))
...
(let ((a ---))
...))
SPECIAL declarations already have this problem. If at toplevel you do
(PROCLAIM '(SPECIAL A)), then you are restricted in the way you can choose
the names of your lexical variables. Which is exactly the reason we
generally spell special variables with *'s.
Sure, this isn't a perfect solution. But I am coming to prefer it to the
existing situation.
While you're at it, you could simplify the scoping rules as well, by simply
not allowing such constructs; the user can always change the name of the
inner "a".
I don't understand what this has to do with it. I don't see why anyone
would generalize my suggestion to such a restriction.
∂23-Jul-86 0002 NGALL@G.BBN.COM Re: DECLARE SPECIAL Considered Confusing
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 23 Jul 86 00:01:49 PDT
Date: 23 Jul 1986 03:00-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: DECLARE SPECIAL Considered Confusing
From: NGALL@G.BBN.COM
To: ALAN@AI.AI.MIT.EDU
Cc: Common-Lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]23-Jul-86 03:00:58.NGALL>
In-Reply-To: <[AI.AI.MIT.EDU].73400.860721.ALAN>
Date: Mon, 21 Jul 86 16:02:37 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: DECLARE SPECIAL Considered Confusing
In-Reply-To: Msg of 20 Jul 1986 18:52-EDT from NGALL at G.BBN.COM
Message-ID: <[AI.AI.MIT.EDU].73400.860721.ALAN>
Actually, the more I think about this as a simplification, the more I like
it. So here is a counter-proposal for rationalizing the semantics of
declarations:
1. All declarations are completely pervasive. That is, if you write
(locally (declare (special foo)) ...)
then every occurance of FOO within the body is taken to be a special
reference or a special binding. The only way to escape from the effects of
a declaration within the body, is to explicitly shadow the declaration with
another. This applies to -all- declarations: FTYPE, INLINE, etc.
How do I shadow the SPECIAL declaration if "every occurance of FOO is
taken to be a ... special binding"? E.g., How can I bind X lexically
in the body of the following: (defun foo (x) (declare (special x))...)
2. Declarations that occur in the bodies of special forms (DEFUN, LET, DO,
etc.), and in LAMBDA expressions, are taken to mean the same thing as if
the entire form was enclosed in a LOCALLY containing the same declarations.
So
(let ,pairs ,@dcls ,@body)
and
(locally ,@dcls (let ,pairs ,@body))
are completely equivalent.
(Since LAMBDA expressions aren't forms, the equivalent using LOCALLY isn't
always completely straightforward to construct. For example, this case:
((lambda ,vars ,@dcls ,@body) ,@vals)
is equivalent to using LOCALLY as follows:
(funcall (locally ,@dcls (function (lambda ,vars ,@body))) ,@vals)
.)
Question: Why isn't LOCALLY just called PROGN?
Answer: Because PROGN doesn't allow declarations :-).
Your proposal completely contradicts the spirit of lexical scoping by
allowing a declaration OUTSIDE THE LEXICAL SCOPE of an entity to
AFFECT that entity. Thus the programmer must look outside the lexical
scope of the entity to determine its type, whether it is special,
whether it is inline, etc. This is BAD language semantics. Sure
PROCLAIM is BAD too, but lets not compound the error.
Also, it makes no sense for one binding to shadow another if the
declarations aren't shadowed also. This is what DCW was alluding to.
It will just confuse the user to have a flat namespace for
declarations and a shadowing namespace for bindings.
-- Nick
∂22-Jul-86 2332 NGALL@G.BBN.COM Re: Some easy ones (?)
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 22 Jul 86 23:31:52 PDT
Date: 23 Jul 1986 02:30-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Some easy ones (?)
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
Date: Mon, 21 Jul 1986 21:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Some easy ones (?)
Message-ID: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
What follows are ten proposals adapted from Steele's list of last
December. These have been discussed before, and I believe that they
should not stir up much new controversy. There are a lot of issues like
this, so I'm hoping that we can deal with these in batches, while
continuing to discuss more difficult issues like declaration scoping.
We shall see. Please read these over and indicate any problems you
discover, or whether they all look OK to you.
The plan is to discuss these things for a week (or more if complexities
arise), then to put the proposals forth in their final form for a last
round of comments, and finally to send the proposals to the technical
committee, who will make the final decisions.
This is something of an experiment. If we can't handle this many simple
things at once, we'll have to deal with issues in smaller batches, but
then it will take twice as long to settle these things.
-- Scott
---------------------------------------------------------------------------
Proposal #5: PARSE-BODY
Extension:
Add a new function (PARSE-BODY body environment documentation-allowed-p).
It pulls apart the body into three parts: a list of DECLARE forms, a
documentation string (or NIL if none), and the body proper. These are
returned in the order body, declarations, and doc-string as three
values. PARSE-BODY may perform macro-expansion (using the given
environment) in order to determine whether an initial macro-call expands
into a DECLARE form or documentation string.
Taking into account the other comments on this function (the ones that
I agree with at least), how about this proposal
(PARSE-BODY body &optional environment
declarations-allowed-p
doc-string-allowed-p)
Parses a BODY argument of the form
({declaration|doc-string}* {form}*)
according to the rules on page ????[Currently, incompletely specified
on pages 67, 153-154] and returns three values: a list of the
DECLARATIONs, the DOC-STRING (or NIL if none), and a list of the FORMS
(which may share structure with the BODY). All the DECLARATIONs and
none of the FORMS will have been MACROEXPANDed and none of the FORMS
will have been. The optional parameter ENVIRONMENT (which defaults to
NIL, which represents the null lexical environment) is used for such
macro expansion.
If the optional parameter DECLARATIONS-ALLOWED-P is true (the
default), then BODY may contain declarations and a doc-string.
Otherwise, if it is NIL, (in which case the argument to
DOC-STRING-ALLOWED-P must also be NIL) an error is signalled if there
are any declarations before the first FORM in BODY (or before the end
of BODY if there are no FORMs).
If the optional parameter DOC-STRING-ALLOWED-P is true (the default),
then the first string encountered before, during, or immediately after
the DECLARATIONs in BODY is returned as the second value. Any
subsequent string is considered a FORM. Otherwise, if it is NIL, then
all strings in BODY are considered FORMs.
[Rationale:
declarations-allowed-p is useful for ensuring that certain bodies do
NOT contain decls, e.g., the 'body' of CASE, PROGN, etc.
declarations-allowed-p=nil -> doc-string-allowed-p=nil since
currently, CLtL does not have ANY bodies that allow a doc-string
without allowing decls.
doc-string-allowed-p is shorter, and uses the correct terminology.
The order of the return values reflects their (typical) order in CLtL.
Decls are left expanded since it is unlikely that anything would care
about their unexpanded form; but the same is not true for forms, so
all of the forms are returned unexpanded.]
---------------------------------------------------------------------------
Proposal #6: Parsing in &BODY
Change (could conceivably break existing code which destructures &body
arguments, but this should be rare as such destructuring is generally
too complex to do via the built in mmechanism):
Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
&body (body-var [declarations-var [doc-string-var]]). If only body-var
appears in parentheses, it means the same as a body-var with no
parentheses. Otherwise, it means to give the original body to
PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is
specified) and then bind the variables to the corresponding values
returned by PARSE-BODY. This is purely a syntactic convenience for the
user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then
call PARSE-BODY himself.
Note: This extension is proposed only for &BODY, not for &REST, so &BODY
will no longer be exactly equivalent to &REST in a DEFMACRO arglist.
[Note: KMP has suggested the syntax (...&body body-var decl-var doc-var).
This does not break any existing code and would allow default and
supplied-p values for the three variables. I (sef) don't think these are
important advantages, and I prefer the syntax proposed above, which is
less confusing to the eye -- my eye, ayway. The proposed format is the
one we discussed on the mailing list earlier and seemed to be favored by
most people.]
How about a compromise?
&body may be follwed by a list of the form
(&forms {var|(var[initform[svar]])}
[&declarations <<ditto>>
[&doc-string <<ditto>>]])
Which means to give the list which would be bound by &rest to and the
environment that would be bound by &environment to PARSE-BODY (with
declarations-allowed-p true iff &declarations is specified, ditto for
doc-string-allowed-p) and then bind the variables to the corresponding
values returned by PARSE-BODY.
This is an upward compatible change (if a list whose first element is
NOT &forms appears after &body, it is destructured in the normal way.
Note that the &forms, etc., parameters may not be destructured [CLtL
should also put such a restriction on other defamcro parameters, e.g.,
&environment, but that is another proposal.]
---------------------------------------------------------------------------
Proposal #7: TYPE-SPECIFIER-P
Proposed extension:
Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time.
I like the idea of a corresponding type-specifier named TYPE-SPECIFIER
(not TYPE). I don't think a second value to indicate 'don't-know' is
necessary. For example, if expanding a type-specifier signals an
error, then it is simply not a vaild type-specifier.
---------------------------------------------------------------------------
Proposal #8: Clarifications to DEFCONSTANT
Clarifications:
Clarify that using DEFCONSTANT to redefine any constant described in the
Common Lisp specification is an error.
Clarify that if the user defines a constant, compiles code that refers
to that constant, and then redefines the constant, then behavior of the
compiled code may be unpredictable. It is an error to execute such
code.
I would change "redefines the constant" to "redefines the constant to
a new, non-eql, value".
Clarify that it is not an error to issue a second DEFCONSTANT command
for an existing constant iff the new value is EQL to the old one.
[That last clarification has not been discussed previously, as far as I
know, but seems to be needed for reloading certain compiled code files,
etc.]
Flush the last clarification. My change makes it unnecessary when
talking about affected compiled code, and it contradicts pg. 56.
Finally, it makes it impossible to change your mind about the value of
a constant (before compiling any code).
---------------------------------------------------------------------------
Proposal #9: Variable Name Conflicts
Clarification:
Specify that it is an error for two parameters (including supplied-p and
&aux parameters) in the same lambda-list to have the same (EQL) name.
[As previous discussion brought out, we could instead allow this case
with the last-bound (rightmost) argument shadowing previous bindings in
the same arglist, but this is certainly bad style and interacts in nasty
ways with the proposed change to the scope of declarations.]
Specify same for LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET,
MV-BIND, and PROG.
---------------------------------------------------------------------------
Proposal #10: Forms That Allow Declarations
Extension:
Permit declarations before the body of a LABELS, FLET, or MACROLET.
Fine. That WAS simple :-).
---------------------------------------------------------------------------
Proposal #11: Contents of Tagbody
Clarification:
Specify that constant forms such as strings may appear at top-level in a
tagbody, but that only symbols and integers are considered to be tags.
It is an error to use anything else as the destination tag for a GO.
[Several forms of this have been kicked around. This seems as good as
any. The original issue was whether you could put something like a
string at top-level and, if so, whether you could go to it.]
Fine.
---------------------------------------------------------------------------
Proposal #12: Unique Names For Tags
Clarification:
Specify that it is an error for the same (EQL) tag to appear more than
once in the body of a TAGBODY. (However, a TAGBODY may have the same
tag as another TAGBODY in which it nests, in which case the tag in the
outer TAGBODY is shadowed, as already specified.)
Fine.
---------------------------------------------------------------------------
Proposal #13: Structure Sharing in Arguments
Clarification:
Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
Similarly, a function that takes a &REST argument should not
destructively modify it because in some implementations its top-level
list structure might share with a list that the user gave as the last
argument to APPLY.
I agree with the suggestions that returning or storing such a list
must be forbidden also. Also, any kind of function/macro call
(regardless of how it was invoked) should be included in this restriction.
---------------------------------------------------------------------------
Proposal #14: THE and VALUES
Clarification:
Specify that in (THE (VALUES ...) form), the form may return more
values, but not fewer, than the number of types specified in the (VALUES
...) form, and that any extra values are of unrestricted type.
Also specify that (THE type form) where type is not (VALUES ...) is
equivalent to (THE (VALUES type) form).
Since the VALUES type-spec is already allowed to contain &optional,
&rest, and &key, I agree with DCP(?) that in
(THE (VALUES...) form), the form must return the 'required' values,
may return the &optional values, and any leftover values are discarded
by THE, unless &rest or &key is specified. I prefer using &rest T to . T.
---------------------------------------------------------------------------
-- Nick
∂23-Jul-86 0045 masinter.pa@Xerox.COM Re: Bawden's Alternate Proposal
Received: from XEROX.COM by SU-AI.ARPA with TCP; 23 Jul 86 00:44:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUL 86 00:45:18 PDT
Date: 23 Jul 86 00:44 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Bawden's Alternate Proposal
In-reply-to: Alan Bawden <ALAN@AI.AI.MIT.EDU>'s message of Wed, 23 Jul
86 01:20:16 EDT
To: common-lisp@SU-AI.ARPA
Message-ID: <860723-004518-1243@Xerox>
Before we get carried away, there are a few advantages to lexical
scoping....
[A simple example:
(defmacro call-double (fn value) `(let((a ,value)) (,fn a a)))
You don't want pervasive declarations in the context of the macro
invocation to muck with what "a" means.
]
One source of problems with "special" declarations is that they talk
about two different things: references & bindings. Since we're
considering radical changes, lets consider separating out the two uses:
Masinter's alternative:
(DECLARE (SPECIAL var1 var2 ...))
only affect the *binding* of var1 and var2. Which binding? Only the one
that they are lexically apparent in. SPECIAL declarations can only occur
in declarations in LAMBDA and LET and are only meaningful for the
variables that are actually bound there.
How do you tell if a *reference* is special or lexical? A reference is
lexical if the variable is lexically apparent, and special if it isn't.
If you want, we can add another declaration (SPECIAL-REFERENCE var1 var2
...) which is like (IGNORE var1 ...) in that its only use is to turn off
compiler warnings. In this case, if you declare something as
USED-FREELY, the compiler won't warn about special references to
variables that aren't PROCLAIMed special.
(Interlisp has this separation: special declarations are done with
SPECVARS, while reference declarations, just there to turn off warnings,
are done with USEDFREE.)
∂23-Jul-86 0418 edsel!bhopal!jonl@navajo.stanford.edu DECLARE SPECIAL Considered Confusing ?
Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 23 Jul 86 04:18:31 PDT
Received: by navajo.stanford.edu; Wed, 23 Jul 86 04:17:11 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA16037; Wed, 23 Jul 86 03:50:10 pdt
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA04163; Wed, 23 Jul 86 03:53:30 PDT
Date: Wed, 23 Jul 86 03:53:30 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8607231053.AA04163@bhopal.edsel.uucp>
To: navajo!NGALL%G.BBN.COM@navajo.stanford.edu
Cc: navajo!ALAN%AI.AI.MIT.EDU@navajo.stanford.edu,
navajo!Common-Lisp%SU-AI.ARPA@navajo.stanford.edu
In-Reply-To: NGALL@G.BBN.COM's message of 23 Jul 1986 03:00-EDT
Subject: DECLARE SPECIAL Considered Confusing ?
Re: your question
"How do I shadow the SPECIAL declaration if "every occurance of FOO is
taken to be a ... special binding"? E.g., How can I bind X lexically
in the body of the following: (defun foo (x) (declare (special x))...)"
I thought Alan's proposal didn't just simply say "every occurance ...",
but rather "every occurance ..., unless shadowed by another declaration".
Thus, assuming there is to be an UNSPECIAL, or LOCAL, declaration, which is
a no-op when the variable isn't declared or proclaimed special, then you can
insulate some small piece of context from the larger lexical context in which
it is embedded by just such a means.
Consider for example:
(defmacro square (form)
`(let ((temp ,form))
(declare (local temp) (notype temp))
(* temp temp)))
Actually, many of us would probably have written "square" as:
(defmacro square (form)
(let ((temp (gensym))) ;or maybe even "(gentemp)"
`(let ((,temp ,form))
(* ,temp ,temp))))
but that is no big issue (you'll probably prefer the former if you
are stuck with an implementation that can't GC symbols).
It seems to me that Alan's proposal infuses declarations with the same
kind of scoping semantics that exists for variable bindings. In the form
(let ((a <something>))
. . .
(let ((a <something-else>))
. . .
))
the meaning of this is "a is bound to something, unless it is bound
to something else"; which is parallel to Alan's notion for declarations
that has (unfortunately) been called "shadowing".
I find the unification of these two scoping rules to be very attractive.
-- JonL --
∂23-Jul-86 0650 RAM@C.CS.CMU.EDU THE VALUES
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jul 86 06:50:30 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 23 Jul 86 09:50:41-EDT
Date: Wed, 23 Jul 1986 09:50 EDT
Message-ID: <RAM.12224974495.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: THE VALUES
In-reply-to: Msg of 21 Jul 1986 21:46-EDT from Scott E. Fahlman <Fahlman>
Well, I think everyone is wrong about this one. (THE (VALUES ...) ...)
specifies the functional type of the continuation. This is in effect
what CLTL already says: "...indicates the parameter list of a function
that, when given to multiple-value-call along with the values, would
be suitable for receiving those values."
I strongly disagree with any proposal which gives THE mandatory
run-time semantics. THE is a declaration --- its presence should not
change the meaning of a correct program. If the form returns too many
values, then the program is in error and the result is undefined.
I agree that it is highly desirable to be able to specify the
type of the first value without worrying about the actual number of
values. To this end, I propose that (THE FOO ...) should be
synonomous with the (THE (VALUES FOO &REST T) ...). This allows one
to say things like (THE FIXNUM (TRUNCATE ...)).
It should also be clarified that the VALUES type specifier may
have &ALLOW-OTHER-KEYS.
Rob
∂23-Jul-86 0720 shebs%utah-orion@utah-cs.arpa Re: Some easy ones (?)
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 23 Jul 86 07:20:37 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA11852; Wed, 23 Jul 86 08:20:50 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA12480; Wed, 23 Jul 86 08:20:47 MDT
Date: Wed, 23 Jul 86 08:20:47 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8607231420.AA12480@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: Some easy ones (?)
Summary:
Expires:
References: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <[G.BBN.COM]23-Jul-86 02:30:50.NGALL> NGALL@G.BBN.COM writes:
> ---------------------------------------------------------------------------
> Proposal #6: Parsing in &BODY
>
> Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
> &body (body-var [declarations-var [doc-string-var]]). If only body-var
> appears in parentheses, it means the same as a body-var with no
> parentheses. Otherwise, it means to give the original body to
> PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is
> specified) and then bind the variables to the corresponding values
> returned by PARSE-BODY. This is purely a syntactic convenience for the
> user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then
> call PARSE-BODY himself.
>
>How about a compromise?
>&body may be follwed by a list of the form
>(&forms {var|(var[initform[svar]])}
> [&declarations <<ditto>>
> [&doc-string <<ditto>>]])
Ugh. This seems like extra hair in the language to save macro writers
1 line of code every once in a while. Remember, if it goes in the language,
then every implementation *must* incur the space overhead, not to mention
that it has to be written about in the standard, in manufacturer's manuals,
in textbooks, ad nauseam. It's just not worth it.
stan
∂23-Jul-86 0740 RAM@C.CS.CMU.EDU (declare (type fixnum ---)) considered etc.
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jul 86 07:40:07 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 23 Jul 86 10:39:55-EDT
Date: Wed, 23 Jul 1986 10:39 EDT
Message-ID: <RAM.12224983442.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA, "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>,
masinter.PA@XEROX.COM
Subject: (declare (type fixnum ---)) considered etc.
In-reply-to: Msg of 22 Jul 1986 16:53-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
Well, I had previously believed that the FIXNUM declaration was
reasonable, but this was based on the erroneous belief that an array
index must be a fixnum. If it is fact the case that some
implementations have small (2↑16) fixnums, then this is a serious
source of non-portability. A possible solution would be to have an
INDEX type which is (INTEGER 0 (ARRAY-DIMENSION-LIMIT)).
In any case, I think there are valid arguments for retaining the
FIXNUM declaration:
1] Much existing code would have to be changed. This code will probably
work on any implementation for some range of inputs.
2] There is precendent for sacrificing portability to gain
efficiency.
The problem with saying something like (SIGNED-BYTE 32) is that it is
probably just as arbitrary as FIXNUM, yet is unlikely to be a good
match for a given implementation. In fact in this particular case,
nearly all implementations on conventional hardware would be forced to
consider bignums.
It seems that FIXNUM is no less portable than FLOAT, since nothing is
guaranteed about float exponent range and precision. A Common Lisp
program which uses floats cannot be totally portable. One could take
this as an argument against the currently system of float types, but
I don't have a better solution.
I suggest that there should be some short integer type which is
defined to have a reasonably large magnitude (> 2↑20). This is
analogous to the float types which have suggested minimum precisions.
Note that CLTL currently suggest (p 14) that FIXNUM be at least
(SIGNED-BYTE 16), so uses of FIXNUM consistent with this can be
considered portable.
Rob
∂23-Jul-86 0814 shebs%utah-orion@utah-cs.arpa Re: (declare (type fixnum ---)) considered etc.
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 23 Jul 86 08:14:44 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA12816; Wed, 23 Jul 86 09:14:48 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA12733; Wed, 23 Jul 86 09:14:45 MDT
Date: Wed, 23 Jul 86 09:14:45 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8607231514.AA12733@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: (declare (type fixnum ---)) considered etc.
Summary:
Expires:
References: <RAM.12224983442.BABYL@C.CS.CMU.EDU>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <RAM.12224983442.BABYL@C.CS.CMU.EDU> RAM@C.CS.CMU.EDU (Rob MacLachlan) writes:
>I suggest that there should be some short integer type which is
>defined to have a reasonably large magnitude (> 2↑20). [...]
Help me, Mr. Wizard, they're trying to add more datatypes to CL!! :-)
stan
∂23-Jul-86 0904 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Computer Implementations Sociologists
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 09:01:24 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48132; Wed 23-Jul-86 11:58:18 EDT
Date: Wed, 23 Jul 86 11:58 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Computer Implementations Sociologists
To: Common-Lisp@SU-AI.ARPA, tcp-ip@SRI-NIC.ARPA
Message-ID: <860723115811.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
I'm wondering if there are any social scientists that study why various
aspects of computers exist the way they do. My current questions relate
to languages and network protocols. Other topics include computer
architectures, operating systems and I'm sure several others.
Languages is an older field. I'm not really interested in a simple
history of FORTRAN or BASIC or COBOL or ADA or CommonLisp. I'm more
interested in the overall motivations, goals and constraints placed upon
the designers, how well the result met the goals, what problems the
language didn't solve, how the goals were found to be faulty, how the
goals change over time (e.g., as memory and disk gets cheaper), etc.
This goes all the way from conception, implementation, revision,
widespread usage, evolution, etc.
Networks are a newer field, but certainly has had its share of good and
bad ideas. Again, I'm not interested in a simply history of the
ARPAnet, LANs, etc. I'm interested in such things as the constraints
under which designers use numeric encoding instead of symbolic values.
Is it host language support? Is it to reduce byte count for 1970 packet
charges that haven't evaporated in this the information age? Is it just
historical inertia? Has anybody studied the "Not made here" syndrome?
What is the cause of it? Is it simple arrogance, or do original
designers plan things too specifically that can be generalized? If so,
do they realize what they are doing, or does one learn to be more
general as one gets older and wiser? How do protocols become imposed on
people? What is the effect of the imposition?
Has anybody studied possible hypocrisy among designers? For example, if
a standard is to be imposed, what if it is known to be unsuitable for
some organization? How many things are done because of underying, and
possibly not realized, job security desires?
Those are the types of questions/debates I'm interested in seeing
outsider study results. I'm sure we all have opinions on some of the
above. I do. Doing some soul searching to learn why one has opinions
can sometimes be very enlightening. Any leads on professionals or
publications that address these?
Replies to me only, please. I'll redistribute replies to interested
individuals. I'd be interested in actively discussing this, but I don't
have time in the short term.
∂23-Jul-86 0931 gls@Think.COM (declare (type fixnum ---)) considered etc.
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86 09:31:22 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Wed, 23 Jul 86 12:31:29 edt
Date: Wed, 23 Jul 86 12:32 EDT
From: Guy Steele <gls@Think.COM>
Subject: (declare (type fixnum ---)) considered etc.
To: common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <RAM.12224983442.BABYL@C.CS.CMU.EDU>
Message-Id: <860723123211.2.GLS@BOETHIUS.THINK.COM>
Date: Wed, 23 Jul 1986 10:39 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
...
It seems that FIXNUM is no less portable than FLOAT, since nothing is
guaranteed about float exponent range and precision. A Common Lisp
program which uses floats cannot be totally portable. One could take
this as an argument against the currently system of float types, but
I don't have a better solution.
One thing one can say is (OR FIXNUM (SIGNED-BYTE 20)), say, which a
sufficiently clever compiler (heh, heh, heh) would understand to mean
"use a fixnum, unless fixnums are less than 20 bits, in which case use
at least 20 bits (whatever that takes)".
--Guy
∂23-Jul-86 0946 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 09:43:48 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48198; Wed 23-Jul-86 12:43:00 EDT
Date: Wed, 23 Jul 86 12:42 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: (declare (type fixnum ---)) considered etc.
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA, Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
masinter.PA@XEROX.COM
In-Reply-To: <RAM.12224983442.BABYL@C.CS.CMU.EDU>
Message-ID: <860723124252.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 1986 10:39 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Well, I had previously believed that the FIXNUM declaration was
reasonable, but this was based on the erroneous belief that an array
index must be a fixnum. If it is fact the case that some
implementations have small (2↑16) fixnums, then this is a serious
source of non-portability. A possible solution would be to have an
INDEX type which is (INTEGER 0 (ARRAY-DIMENSION-LIMIT)).
In any case, I think there are valid arguments for retaining the
FIXNUM declaration:
1] Much existing code would have to be changed. This code will probably
work on any implementation for some range of inputs.
In my opinion, that is one of THE poorest reasons to keep it. Why have
any semantics at all?
2] There is precendent for sacrificing portability to gain
efficiency.
The problem with saying something like (SIGNED-BYTE 32) is that it is
probably just as arbitrary as FIXNUM, yet is unlikely to be a good
match for a given implementation. In fact in this particular case,
nearly all implementations on conventional hardware would be forced to
consider bignums.
Back to semantics again. How can a program that specifies it is using
fixnums possibly return the right answer reliably if the size of the
fixnum is variable by the implementation? If a program is going to deal
with (signed-byte 12) it should say that, instead of FIXNUM. Does the
following make anybody feel any better:
(eval-when (compile)
(unless (subtypep '(signed-byte 20) 'fixnum)
(warn "This program is using (unsigned-byte 20), ~@
but these a subtype of fixnum in this ~@
implementation. Efficiency will be lost!")))
Using (signed-byte 20) >>properly<< reflects the intent of the
programmer, and the above warns that they will not be efficient.
It seems that FIXNUM is no less portable than FLOAT, since nothing is
guaranteed about float exponent range and precision. A Common Lisp
program which uses floats cannot be totally portable. One could take
this as an argument against the currently system of float types, but
I don't have a better solution.
Good point. The difference with fixnums is that they are (a) exact and
(b) have overflow provision (into bignums).
I suggest that there should be some short integer type which is
defined to have a reasonably large magnitude (> 2↑20). This is
analogous to the float types which have suggested minimum precisions.
Note that CLTL currently suggest (p 14) that FIXNUM be at least
(SIGNED-BYTE 16), so uses of FIXNUM consistent with this can be
considered portable.
I agree with shebs: we don't need another data type.
BTW, When I say (signed-byte 32) I really mean (signed-byte 31) and when
you say (signed-byte 16) you really mean (signed-byte 15).
∂23-Jul-86 0949 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA JIS WG start in japan
Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 09:49:21 PDT
Received: from utokyo-relay by csnet-relay.csnet id ar02912; 23 Jul 86 12:43 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA03821; Wed, 23 Jul 86 18:30:43+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA27066; Wed, 23 Jul 86 18:15:23+0900
Date: Wed, 23 Jul 86 18:15:23+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607230915.AA27066@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, fahlman@C.CS.CMU.EDU,
ida%u-tokyo.junet@CSNET-RELAY.ARPA, mathis@ADA20.ISI.EDU
Subject: JIS WG start in japan
We had the first meeting of JIS Lisp WG on July 22.
This means japan start to try to find a standard of Lisp officially.
It will take a long time to make a final decision.
Members are:
Chair: M.Ida (Aoyama Gakuin University)
H. Murao (Univ. of Tokyo)
H. Motoyoshi (ETL, MITI)
T. Yuasa (Kyoto university)
N. Inada (Riken)
S. Kobayashi (Toshiba)
I. Takeuchi (NTT)
M. Yasumura (Hitachi)
M. Kuroda (Mitsubishi)
H. Nakamura (Fujitsu)
A. Nagasaka (Oki)
T. Kurokawa (IBM japan)
Y. Hashimoto (NEC)
S. Itoh (MITI)
This WG is the official working group to prepare a draft for JIS LISP.
I have been chairing another committee named Jeida Common Lisp committee,
which is a group
of CommonLisp enthusiastic persons from more than 26 organizations
including the companies which send members to the JIS WG.
(Under the Jeida committee, there are four WGs; subset WG,
Object oriented WG, Kanji WG and bboard WG)
I think Jeida Common Lisp committee roughly corresponds to common-lisp@su-ai.
JIS Lisp WG will roughly correspond to the comming ANSI/ISO committee.
The base for JIS will be also Common Lisp, I believe.
But, we will start from the scratch for the WG.
I want to keep a good relation to the USA committee.
Thank you.
M.ida
ida@utokyo-relay.csnet
----
∂23-Jul-86 0955 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM THE VALUES
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 09:54:45 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48207; Wed 23-Jul-86 12:54:20 EDT
Date: Wed, 23 Jul 86 12:54 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: THE VALUES
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12224974495.BABYL@C.CS.CMU.EDU>
Message-ID: <860723125416.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 1986 09:50 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Well, I think everyone is wrong about this one. (THE (VALUES ...) ...)
specifies the functional type of the continuation. This is in effect
what CLTL already says: "...indicates the parameter list of a function
that, when given to multiple-value-call along with the values, would
be suitable for receiving those values."
I strongly disagree with any proposal which gives THE mandatory
run-time semantics. THE is a declaration --- its presence should not
change the meaning of a correct program. If the form returns too many
values, then the program is in error and the result is undefined.
I agree that it is highly desirable to be able to specify the
type of the first value without worrying about the actual number of
values. To this end, I propose that (THE FOO ...) should be
synonomous with the (THE (VALUES FOO &REST T) ...). This allows one
to say things like (THE FIXNUM (TRUNCATE ...)).
OK, I can buy that. I still want a form for run-time semantics for the
purposes of multiple-value-call and multiple-value-list. Something like
(take-values <something>
<form>)
where <something> is not evaluated and can be either a non-negative integer
which is the number of values, or a list of type specifiers. (An
integer is shorthand for (t t ...).) The take-values form returns
exactly the number of specified values, by truncating or padding the
values returned by <form> as necessary. This can be naively implemented
as a macro given what is currently in CLtL, but I think it is useful
enough for some compilers to take advantage of it that it should be
considered part of the language.
It should also be clarified that the VALUES type specifier may
have &ALLOW-OTHER-KEYS.
∂23-Jul-86 1009 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: Some easy ones (?)
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 10:08:57 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48225; Wed 23-Jul-86 13:08:34 EDT
Date: Wed, 23 Jul 86 13:08 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Some easy ones (?)
To: NGALL@G.BBN.COM, Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>
Message-ID: <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 23 Jul 1986 02:30-EDT
From: NGALL@G.BBN.COM
Taking into account the other comments on this function (the ones that
I agree with at least), how about this proposal
(PARSE-BODY body &optional environment
declarations-allowed-p
doc-string-allowed-p)
Parses a BODY argument of the form
({declaration|doc-string}* {form}*)
...
Until somebody says something profound to change my mind, I hold that if
a "body" may not contain either declarations or doc-strings, it is not a
true body, and therefore you have no right to call PARSE-BODY. I have
no idea what the reference to CASE and PROGN was. If the claim that
each clause of a CASE contained a "body" you are wrong; it contains an
"implicit PROGN". Implicit PROGNs are not suitable arguments to
PARSE-BODY.
Proposal #7: TYPE-SPECIFIER-P
Proposed extension:
Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time.
I like the idea of a corresponding type-specifier named TYPE-SPECIFIER
(not TYPE).
You're right. Friendly ammendment accepted.
I don't think a second value to indicate 'don't-know' is
necessary. For example, if expanding a type-specifier signals an
error, then it is simply not a vaild type-specifier.
Proposal #13: Structure Sharing in Arguments
Clarification:
Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
Similarly, a function that takes a &REST argument should not
destructively modify it because in some implementations its top-level
list structure might share with a list that the user gave as the last
argument to APPLY.
I agree with the suggestions that returning or storing such a list
must be forbidden also. Also, any kind of function/macro call
(regardless of how it was invoked) should be included in this restriction.
That may have been my suggestion, but there was a lot of other stuff I
said that this whole thing is a cop-out. I think not being able to
destructively modify it is equivalent to not being allowed to store it
or return it. (More on this in the next piece of mail.) This leads to
very unintuitive behavior and hard/very-hard/very-very-hard to find
bugs. How do you KNOW if the argument is somebody's apply arg. See
next piece of mail.
Proposal #14: THE and VALUES
Clarification:
Specify that in (THE (VALUES ...) form), the form may return more
values, but not fewer, than the number of types specified in the (VALUES
...) form, and that any extra values are of unrestricted type.
Also specify that (THE type form) where type is not (VALUES ...) is
equivalent to (THE (VALUES type) form).
Since the VALUES type-spec is already allowed to contain &optional,
&rest, and &key, I agree with DCP(?) that in
(THE (VALUES...) form), the form must return the 'required' values,
may return the &optional values, and any leftover values are discarded
by THE, unless &rest or &key is specified. I prefer using &rest T to . T.
I'll have to think about this. I just responded to RAM going along with
his contention that THE is a declaration and should not change the
runtime semantics. I the last 10 minutes of thinking about this issue
I still agree with him: THE is for declaratative purposes, not
procedural purposes. On the procedural side, I suggested a TAKE-VALUES
form.
∂23-Jul-86 1022 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Structure sharing in arguments
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 10:21:51 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48241; Wed 23-Jul-86 13:21:25 EDT
Date: Wed, 23 Jul 86 13:21 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Structure sharing in arguments
To: hpfclp!diamant@hplabs.HP.COM, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 23 Jul 86 00:39 EDT from hpfclp!diamant@hplabs.HP.COM
Message-ID: <860723132120.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 22 Jul 86 21:39:37 pdt
From: hpfclp!diamant@hplabs.HP.COM
From: Scott Fahlman <fahlman@C.CS.CMU.EDU>
Subject: Some easy ones (?)
Proposal #13: Structure Sharing in Arguments
Clarification:
Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
Similarly, a function that takes a &REST argument should not
destructively modify it because in some implementations its top-level
list structure might share with a list that the user gave as the last
argument to APPLY.
I don't really care whether you add a restriction not to do destructive
operations on a &REST or &BODY argument, but it better be clear that the
list returned may not be something which will go away on exiting the function
(which could happen if the parameter list were stored on the stack and a
pointer to that list was returned -- apparently what Symbolics does).
Nothing currently in CLtL limits me from doing the following (nor should it):
(defun foo (&rest x) x)
(defun list (&rest list) list)
(defun copy-list (list) (apply #'list list))
[Yes, Symbolics uses stack-consed &rest lists, and they will screw you
every now and then. >>> My view of our current position <<< is that the
efficiency issues (e.g., not calling copy-list on every &rest arg) are
outweighed by the programmer resources needed to implement the copying
only when necessary.]
I'm fairly convinced that disallowing destructive operations on &rest
lists is funtionally equivalent to not being allowed to store them in
stable storage or to return them. I think my first proof caused CLtL to
dictate some aspects of function calls. I'm looking for a proof that is
within the bounds of CLtL that does have such dictations. Maybe there
aren't any. Maybe I'm wrong and they aren't equivalent, but I suspect
they are.
∂23-Jul-86 1135 vanroggen%bach.decnet@hudson.dec.com proposals 5-14
Received: from HUDSON.DEC.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86 11:35:17 PDT
Date: 23 Jul 86 14:30:00 EST
From: "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>
Subject: proposals 5-14
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: vanroggen
Reply-To: "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>
#5: I also think the environment argument should go last, much like other
functions currently do, and both the environment argument and the
doc-allowed-p argument should be optional, defaulting to NIL. Returning
the declarations without DECLARE's in them is a good idea too.
#6: I'd prefer KMP's syntax, because it's compatible and doesn't
look like it's giving a default value to the body.
#9: I assume this really means the same symbol, not the same string as
a name (and certainly not by EQL).
#11: Any reason why we still allow integers? If we want to keep them,
then why not allow characters and other numbers?
#13: The restriction on not modifying code (provided by &REST and &BODY)
sounds reasonable, but what about that given by &WHOLE? This would
seem to follow, yet it would make displacing macros harder to implement.
But I basically disagree with the proposal. &REST should always
cons up a true list which the function can manipulate and return.
CAR and CDR should work on real conses only, not temporary ones too.
If we really want to add a language feature to avoid definite consing,
add another lambda-list keyword and ARG/LISTIFY. Otherwise we should
let clever software and hardware try to avoid unnecessary consing.
---Walter
------
∂23-Jul-86 1154 DLW@QUABBIN.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 11:53:50 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23157; Wed 23-Jul-86 14:53:13 EDT
Date: Wed, 23 Jul 86 14:54 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: (declare (type fixnum ---)) considered etc.
To: DCP@QUABBIN.SCRC.Symbolics.COM, RAM@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA, Fahlman@CMU-CS-C.ARPA,
masinter.PA@XEROX.ARPA
In-Reply-To: <860723124252.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860723145444.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 86 12:42 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 1986 10:39 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
It seems that FIXNUM is no less portable than FLOAT, since nothing is
guaranteed about float exponent range and precision. A Common Lisp
program which uses floats cannot be totally portable. One could take
this as an argument against the currently system of float types, but
I don't have a better solution.
Good point. The difference with fixnums is that they are (a) exact and
(b) have overflow provision (into bignums).
All this means to me is that FLOAT is wrong as well. Table 2-1, page
17, specifies "recommended" minimum sizes for the floating types. I
originally argued that these should be required minimum sizes, for
exactly the reasons we're discussing here, and I still think they should
be. A "recommendation" is meaningless if you are trying to write code
and feel secure that it will run in other implementations of CL.
∂23-Jul-86 1158 DLW@QUABBIN.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 11:57:48 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23159; Wed 23-Jul-86 14:57:04 EDT
Date: Wed, 23 Jul 86 14:58 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: (declare (type fixnum ---)) considered etc.
To: gls@Think.COM, common-lisp@SU-AI.ARPA
In-Reply-To: <860723123211.2.GLS@BOETHIUS.THINK.COM>
Message-ID: <860723145835.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 86 12:32 EDT
From: Guy Steele <gls@Think.COM>
One thing one can say is (OR FIXNUM (SIGNED-BYTE 20)), say, which a
sufficiently clever compiler (heh, heh, heh) would understand to mean
"use a fixnum, unless fixnums are less than 20 bits, in which case use
at least 20 bits (whatever that takes)".
What is the advantage of using this instead of (SIGNED-BYTE 20)?
∂23-Jul-86 1231 Cassels@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: (declare (type fixnum ---)) considered etc.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 12:28:22 PDT
Received: from KRYPTON.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48343; Wed 23-Jul-86 15:26:37 EDT
Date: Wed, 23 Jul 86 15:26 EDT
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: (declare (type fixnum ---)) considered etc.
To: masinter.pa@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860721-190646-2493@Xerox>
Message-ID: <860723152656.1.CASSELS@KRYPTON.SCRC.Symbolics.COM>
Date: 21 Jul 86 19:02 PDT
From: masinter.pa@Xerox.COM
The fixnum declaration is one of the easiest things to remove.
a) Implementations that support (or need) fixnum declarations can add
them to their extension. This is clearly allowed by the spec, but it
becomes something that is an implementation's private extension rather
than part of the public, portable standard. The cost to implementors is
zero.
Why not leave it, but put it in the SYSTEM: package? That way, users
are reminded that they are doing something which is
implementation-dependent. Isn't this what that package is for? System
programmers, who need to refer to it, will probably be :USEing SYSTEM
anyway. [Systems programming in Lisp? Surely you jest! :-]
Are there any other symbols which ought to go in SYSTEM:?
b) Users who have code that has fixnum declarations could add,
trivially, a
(deftype fixnum () ...)
Or import the symbol.
c) The intent of fixnum declarations is reasonably supported by a much
more portable expression where the range of a variable is declared
explicitly rather than depending on implementation-dependent fixnum
ranges.
I agree. If you're going to use declarations at all, they might as well
have some real semantic meaning. I understand that the major current
use is to encourage smart compilers on stupid hardware to generate
more efficient code, rather than to supply program-specific semantics.
But we should encourage users to use more meaningful declarations.
I don't know the source of the "certainly" in your message.
∂23-Jul-86 1245 greek%bach.decnet@hudson.dec.com Oops, sorry.
Received: from HUDSON.DEC.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86 12:45:04 PDT
Date: 23 Jul 86 15:27:00 EST
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Subject: Oops, sorry.
To: "common-lisp" <common-lisp@su-ai.ARPA>
Reply-To: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Yes, my comment about pervasive declarations did mean to refer to
Alan Bawden's proposal, not Nick's. Again, we should be very careful
to avoid situations where one declaration can refer to multiple
entities with the same name.
- Paul
------
∂23-Jul-86 1258 RAM@C.CS.CMU.EDU (declare (type fixnum ---)) considered etc.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 86 12:57:49 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 23 Jul 86 15:53:25-EDT
Date: Wed, 23 Jul 1986 15:53 EDT
Message-ID: <RAM.12225040519.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Robert A. Cassels" <Cassels@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: (declare (type fixnum ---)) considered etc.
In-reply-to: Msg of 23 Jul 1986 15:26-EDT from Robert A. Cassels <Cassels at STONY-BROOK.SCRC.Symbolics.COM>
Almost every other language in the entire world has a "INTEGER"
type which has an ill-defined, fixed precision. If Common Lisp is
going to have comparable performance to these languages when running
on the same hardware, then it is going to have to be comparably
inelegant.
Rob
∂23-Jul-86 1409 FREEMAN@SUMEX-AIM.ARPA Re: Some easy ones (?)
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 86 14:08:36 PDT
Date: Wed 23 Jul 86 13:59:34-PDT
From: Andy Freeman <FREEMAN@SUMEX-AIM.ARPA>
Subject: Re: Some easy ones (?)
To: NGALL@BBNG.ARPA
cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>
Message-ID: <12225052592.76.FREEMAN@SUMEX-AIM.ARPA>
Nick (NGALL@G.BBN.COM) replied to Fahlman:
Proposal #9: Variable Name Conflicts
Clarification:
Specify that it is an error for two parameters (including
supplied-p and &aux parameters) in the same lambda-list to
have the same (EQL) name.
[As previous discussion brought out, we could instead allow this
case with the last-bound (rightmost) argument shadowing previous
bindings in the same arglist, but this is certainly bad style and
interacts in nasty ways with the proposed change to the scope of
declarations.]
Specify same for LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET,
MV-BIND, and PROG.
I don't know about DO*, but LET* should be able to shadow previous names.
The restriction seems reasonable for the others mentioned.
-andy
-------
∂23-Jul-86 1549 masinter.pa@Xerox.COM Re: (declare (type fixnum ---)) considered etc.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86 15:48:40 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUL 86 15:46:56 PDT
Date: 23 Jul 86 15:45 PDT
From: masinter.pa@Xerox.COM
Subject: Re: (declare (type fixnum ---)) considered etc.
In-Reply-To: <RAM.12224983442.BABYL@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Message-ID: <860723-154656-1964@Xerox>
FLOAT is more portable than FIXNUM. Portable implementations which
generate single-float in one implementation will continue to generate
single-float in another implementation, even if the meaning of
single-float differs in the two implementations. There are few functions
that will propagate any change in the floating point precision of a
value from one declaration-type to another; if you have something that
deals exclusively in SINGLE-FLOAT, then * and + aren't suddenly going to
return an unexpected DOUBLE-FLOAT. With FIXNUM, the most innocuous *
might take something that is FIXNUM and produce a non-FIXNUM; the
boundary between FIXNUM and BIGNUM invisible to most of the language.
Larry
[two clarifications: in Xerox Common Lisp, the FIXNUM range is
(signed-byte 17), and FIXNUM declarations are ignored, because all of
the opcodes do generic arithmetic, so I didn't actually have to *do*
anything about the bogus FIXNUM declarations.]
∂23-Jul-86 1630 kempf%hplabsc@hplabs.HP.COM Recursive Compilation?
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86 16:29:54 PDT
Received: from hplabsc by hplabs.HP.COM ; Wed, 23 Jul 86 16:29:39 pdt
Received: by hplabsc ; Wed, 23 Jul 86 16:29:10 pdt
Date: Wed, 23 Jul 86 16:29:10 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8607232329.AA08900@hplabsc>
To: common-lisp@su-ai.ARPA
Subject: Recursive Compilation?
Cc: snyder%hplabsc@hplabs.HP.COM
In the process of bringing up CommonLoops, we ran into an interesting
issue regarding the compiler. We would like to require CommonLoops
at compile time, so that we don't have to build it into the
compiler but just have it around when we're compiling something.
However, it compiles something at load time (immediate reason not
apparent, possibly for speed, also maybe something doesn't work
interpreted). This causes the compiler to be invoked recursively,
which signals an error. I can't find anything in CLtL to indicate
that compilation SHOULDN'T be recursive, but the environmental
problems with making it so would seem to be pretty hairy (another
set of bindings for variables in compiler-let?, etc.). Does
anybody have any comments?
Jim Kempf hplabs!kempf
∂23-Jul-86 1819 JAR@AI.AI.MIT.EDU Recursive Compilation?
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 86 18:19:16 PDT
Date: Wed, 23 Jul 86 21:28:48 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Recursive Compilation?
To: kempf%hplabsc@HPLABS.HP.COM
cc: common-lisp@SU-AI.ARPA, snyder%hplabsc@HPLABS.HP.COM
In-reply-to: Msg of Wed 23 Jul 86 16:29:10 pdt from Jim Kempf <kempf%hplabsc at hplabs.HP.COM>
Message-ID: <[AI.AI.MIT.EDU].74639.860723.JAR>
Date: Wed, 23 Jul 86 16:29:10 pdt
From: Jim Kempf <kempf%hplabsc at hplabs.HP.COM>
... I can't find anything in CLtL to indicate
that compilation SHOULDN'T be recursive, but the environmental
problems with making it so would seem to be pretty hairy (another
set of bindings for variables in compiler-let?, etc.). Does
anybody have any comments?
Yes, me, I have a comment.
Compilers ought to be re-entrant. There's no excuse for them not to be.
COMPILER-LET should be flushed, since MACROLET does what COMPILER-LET
was intended to do, and does it correctly.
- Jonathan
∂23-Jul-86 1843 NGALL@G.BBN.COM Re: Some easy ones (?)
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 18:43:07 PDT
Date: 23 Jul 1986 21:39-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Some easy ones (?)
From: NGALL@G.BBN.COM
To: FREEMAN@SUMEX-AIM.ARPA
Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]23-Jul-86 21:39:54.NGALL>
In-Reply-To: <12225052592.76.FREEMAN@SUMEX-AIM.ARPA>
Date: Wed 23 Jul 86 13:59:34-PDT
From: Andy Freeman <FREEMAN@SUMEX-AIM.ARPA>
Nick (NGALL@G.BBN.COM) replied to Fahlman:
Proposal #9: Variable Name Conflicts
Clarification:
Specify that it is an error for two parameters (including
supplied-p and &aux parameters) in the same lambda-list to
have the same (EQL) name.
[As previous discussion brought out, we could instead allow this
case with the last-bound (rightmost) argument shadowing previous
bindings in the same arglist, but this is certainly bad style and
interacts in nasty ways with the proposed change to the scope of
declarations.]
Specify same for LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET,
MV-BIND, and PROG.
I don't know about DO*, but LET* should be able to shadow previous names.
The restriction seems reasonable for the others mentioned.
-andy
Why should LET* be able to shadow previous names when LAMBDA expressions
cannot?
-- Nick
∂23-Jul-86 1904 NGALL@G.BBN.COM Re: Declaration before variable
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 19:04:21 PDT
Date: 23 Jul 1986 22:01-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Declaration before variable
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]23-Jul-86 22:01:53.NGALL>
In-Reply-To: The message of 23 Jul 1986 1252-PDT from Rem@IMSSS
Date: 23 Jul 1986 1252-PDT
From: Rem@IMSSS
To: NGALL%G.BBN.COM@SCORE
Subject: Declaration before variable
...
Perhaps LISP should do this:
(DEFUN (STRING FOO) ((INTEGER X1 X2) (STRING S) (REAL Z))
...)
I.e. anywhere a simple name can appear to introduce a new binding
of a variable or name of function, a list of two elements can appear
to both introduce the name and tell its type, including SPECIAL etc.
Anywhere a sequence of names can appear, a list of more than two
elements can appear, where the first element is the type and the
remaining elements are names, thus ... (INTEGER X1 X2) ... has the
same effect as ... (INTEGER X1) (INTEGER X2) ...
This would make it absolutely clear which value is being declared,
instead of this crock:
(DE FOO (X1 X2 X Z)
(DECLARE (INTEGER X1 X2) (STRING X [SIC]) (REAL Z))
...)
where we have to know that the declare affects the X1 etc. which have
already appeared earlier as well as usages of X1 etc. that appear
later, and may or may not affect deeper bindings X1 etc. but you
have to read the manual to find out which ones it affects.
Should my idea be submitted to CL discussion?? (does it have any merit?)
I would love such a declaration scheme. I did not propose such a
radical change since I felt that, while some implementors had
expressed interest in 'cleaning up' the semantics of declarations, no
one wanted a really radical change.
In my proposal, I kept as close to the syntax and semantics of current
declarations as I could. The only real 'change', is that first
proposed by Pavel: a declaration should not have a scope greater than
the object to which it refers.
If everyone is willing to consider a radical change to decls, I second
REMs proposal.
-- Nick
∂23-Jul-86 1930 NGALL@G.BBN.COM Re: Some easy ones (?)
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 19:30:05 PDT
Date: 23 Jul 1986 22:27-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Some easy ones (?)
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Cc: Fahlman@C.CS.CMU.EDU
Message-ID: <[G.BBN.COM]23-Jul-86 22:27:40.NGALL>
In-Reply-To: <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 86 13:08 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
To: NGALL@G.BBN.COM, Fahlman@C.CS.CMU.EDU
Subject: Re: Some easy ones (?)
In-Reply-To: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>
Message-ID: <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 23 Jul 1986 02:30-EDT
From: NGALL@G.BBN.COM
Taking into account the other comments on this function (the ones that
I agree with at least), how about this proposal
(PARSE-BODY body &optional environment
declarations-allowed-p
doc-string-allowed-p)
Parses a BODY argument of the form
({declaration|doc-string}* {form}*)
...
Until somebody says something profound to change my mind, I hold that if
a "body" may not contain either declarations or doc-strings, it is not a
true body, and therefore you have no right to call PARSE-BODY. I have
no idea what the reference to CASE and PROGN was. If the claim that
each clause of a CASE contained a "body" you are wrong; it contains an
"implicit PROGN". Implicit PROGNs are not suitable arguments to
PARSE-BODY.
This may not be profound, but its true. A robust macro definition of
CASE, i.e., one that performs an expansion time check to ensure that
the initial forms after the KEYFORM are not declarations, can be
written much more easily with DECLARATIONS-ALLOWED-P, e.g.,
(defmacro case (keyform &rest clauses &environment env)
(multiple-value-bind (decls doc clauses)
(parse-body clauses env nil)
(declare (ignore decls doc))
;; At this point I can rest assured that parse-body has detected
;; any illegal declarations.
...)
Things are easier still if we adopt my proposal for &body:
(defmacro case (keyform &body (&forms clauses))
;; At this point I can rest assured that parse-body has detected
;; any illegal declarations.
...)
Profound enough?
-- Nick
∂23-Jul-86 1943 NGALL@G.BBN.COM Re: THE VALUES
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 19:43:05 PDT
Date: 23 Jul 1986 22:40-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: THE VALUES
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Cc: RAM@C.CS.CMU.EDU
Message-ID: <[G.BBN.COM]23-Jul-86 22:40:33.NGALL>
In-Reply-To: <860723125416.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 86 12:54 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
Subject: THE VALUES
In-Reply-To: <RAM.12224974495.BABYL@C.CS.CMU.EDU>
Message-ID: <860723125416.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 1986 09:50 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Well, I think everyone is wrong about this one. (THE (VALUES ...) ...)
specifies the functional type of the continuation. This is in effect
what CLTL already says: "...indicates the parameter list of a function
that, when given to multiple-value-call along with the values, would
be suitable for receiving those values."
I strongly disagree with any proposal which gives THE mandatory
run-time semantics. THE is a declaration --- its presence should not
change the meaning of a correct program. If the form returns too many
values, then the program is in error and the result is undefined.
Agreed.
I agree that it is highly desirable to be able to specify the
type of the first value without worrying about the actual number of
values. To this end, I propose that (THE FOO ...) should be
synonomous with the (THE (VALUES FOO &REST T) ...). This allows one
to say things like (THE FIXNUM (TRUNCATE ...)).
Agreed.
OK, I can buy that. I still want a form for run-time semantics for the
purposes of multiple-value-call and multiple-value-list. Something like
(take-values <something>
<form>)
where <something> is not evaluated and can be either a non-negative integer
which is the number of values, or a list of type specifiers. (An
integer is shorthand for (t t ...).) The take-values form returns
exactly the number of specified values, by truncating or padding the
values returned by <form> as necessary. This can be naively implemented
as a macro given what is currently in CLtL, but I think it is useful
enough for some compilers to take advantage of it that it should be
considered part of the language.
Hmmm... I'll think about this one. I dont like the name or the
integer stuff, but I think there is a need for such a form.
It should also be clarified that the VALUES type specifier may
have &ALLOW-OTHER-KEYS.
Agreed.
-- Nick
∂23-Jul-86 2021 NGALL@G.BBN.COM Re: (declare (type fixnum ---)) considered etc.
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 20:20:59 PDT
Date: 23 Jul 1986 23:18-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: (declare (type fixnum ---)) considered etc.
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Cc: RAM@C.CS.CMU.EDU, Fahlman@C.CS.CMU.EDU
Cc: masinter.PA@XEROX.COM
Message-ID: <[G.BBN.COM]23-Jul-86 23:18:31.NGALL>
In-Reply-To: <860723124252.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 86 12:42 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: (declare (type fixnum ---)) considered etc.
In-Reply-To: <RAM.12224983442.BABYL@C.CS.CMU.EDU>
Message-ID: <860723124252.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 1986 10:39 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Well, I had previously believed that the FIXNUM declaration was
reasonable, but this was based on the erroneous belief that an array
index must be a fixnum. If it is fact the case that some
implementations have small (2↑16) fixnums, then this is a serious
source of non-portability. A possible solution would be to have an
INDEX type which is (INTEGER 0 (ARRAY-DIMENSION-LIMIT)).
My solution is to write (integer 0 #.array-dimension-limit).
It works just fine.
With such CL constants, I don't see the need for a FIXNUM type specifier.
-- Nick
∂23-Jul-86 2038 NGALL@g.bbn.com Re: DECLARE SPECIAL Considered Confusing ?
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 86 20:37:55 PDT
Received: from G.BBN.COM ([192.1.2.67]) by navajo.stanford.edu with TCP; Wed, 23 Jul 86 20:34:30 PDT
Date: 23 Jul 1986 23:31-EDT
Sender: NGALL@g.bbn.com
Subject: Re: DECLARE SPECIAL Considered Confusing ?
From: NGALL@g.bbn.com
To: edsel!bhopal!jonl@NAVAJO.STANFORD.EDU
Cc: navajo!ALAN%AI.AI.MIT.EDU@NAVAJO.STANFORD.EDU
Cc: navajo!Common-Lisp%SU-AI.ARPA@NAVAJO.STANFORD.EDU
Message-Id: <[G.BBN.COM]23-Jul-86 23:31:54.NGALL>
In-Reply-To: <8607231053.AA04163@bhopal.edsel.uucp>
Date: Wed, 23 Jul 86 03:53:30 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
To: navajo!NGALL%G.BBN.COM@navajo.stanford.edu
Subject: DECLARE SPECIAL Considered Confusing ?
In-Reply-To: NGALL@G.BBN.COM's message of 23 Jul 1986 03:00-EDT
Message-ID: <8607231053.AA04163@bhopal.edsel.uucp>
Re: your question
"How do I shadow the SPECIAL declaration if "every occurance of FOO is
taken to be a ... special binding"? E.g., How can I bind X lexically
in the body of the following: (defun foo (x) (declare (special x))...)"
I thought Alan's proposal didn't just simply say "every occurance ...",
but rather "every occurance ..., unless shadowed by another declaration".
Thus, assuming there is to be an UNSPECIAL, or LOCAL, declaration, which is
a no-op when the variable isn't declared or proclaimed special, then you can
insulate some small piece of context from the larger lexical context in which
it is embedded by just such a means.
I was assuming there wasn't an UNSPECIAL or LOCAL, since any
declaration proposal that requires such, is too radical a change for
my taste.
Consider for example:
(defmacro square (form)
`(let ((temp ,form))
(declare (local temp) (notype temp))
(* temp temp)))
Actually, many of us would probably have written "square" as:
(defmacro square (form)
(let ((temp (gensym))) ;or maybe even "(gentemp)"
`(let ((,temp ,form))
(* ,temp ,temp))))
but that is no big issue (you'll probably prefer the former if you
are stuck with an implementation that can't GC symbols).
It seems to me that Alan's proposal infuses declarations with the same
kind of scoping semantics that exists for variable bindings. In the form
(let ((a <something>))
. . .
(let ((a <something-else>))
. . .
))
the meaning of this is "a is bound to something, unless it is bound
to something else"; which is parallel to Alan's notion for declarations
that has (unfortunately) been called "shadowing".
I think all the other proposals have this same property (but none of
them require hairy changes like a LOCAL decl-spec).
I find the unification of these two scoping rules to be very attractive.
Me too. That's why my proposal incorporates it.
-- Nick
∂23-Jul-86 2101 NGALL@G.BBN.COM Re: Bawden's Alternate Proposal
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 20:51:45 PDT
Date: 23 Jul 1986 23:48-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Bawden's Alternate Proposal
From: NGALL@G.BBN.COM
To: masinter.pa@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]23-Jul-86 23:48:21.NGALL>
In-Reply-To: <860723-004518-1243@Xerox>
Date: 23 Jul 86 00:44 PDT
From: masinter.pa@Xerox.COM
To: common-lisp@SU-AI.ARPA
Subject: Re: Bawden's Alternate Proposal
In-Reply-To: Alan Bawden <ALAN@AI.AI.MIT.EDU>'s message of Wed, 23 Jul
86 01:20:16 EDT
Message-ID: <860723-004518-1243@Xerox>
...
One source of problems with "special" declarations is that they talk
about two different things: references & bindings. Since we're
considering radical changes, lets consider separating out the two uses:
Masinter's alternative:
(DECLARE (SPECIAL var1 var2 ...))
only affect the *binding* of var1 and var2. Which binding? Only the one
that they are lexically apparent in. SPECIAL declarations can only occur
in declarations in LAMBDA and LET and are only meaningful for the
variables that are actually bound there.
How do you tell if a *reference* is special or lexical? A reference is
lexical if the variable is lexically apparent, and special if it isn't.
If you want, we can add another declaration (SPECIAL-REFERENCE var1 var2
...) which is like (IGNORE var1 ...) in that its only use is to turn off
compiler warnings. In this case, if you declare something as
USED-FREELY, the compiler won't warn about special references to
variables that aren't PROCLAIMed special.
(Interlisp has this separation: special declarations are done with
SPECVARS, while reference declarations, just there to turn off warnings,
are done with USEDFREE.)
I contend (as I did in my proposal) that not just SPECIAL, but ALL
decl-specs (exluding optimize and declaration) "talk about two
different things: references & bindings." Do you want to double the
number of decl-specs, one for bindings and one for references? I
don't.
Under my proposal, it is obvious from context whether a declaration is
talking about a binding or just about references: If a declaration
about NAME appears in the body of a form that is binding NAME, then
the declaration is talking about the binding, otherwise it is talking
about references. Simple.
-- Nick
∂23-Jul-86 2101 NGALL@G.BBN.COM Re: Proposal about lambda-list params
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 20:57:42 PDT
Date: 23 Jul 1986 23:55-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Proposal about lambda-list params
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]23-Jul-86 23:55:15.NGALL>
The following thought just struck me. If we change CL to outlaw
things like (lambda (x x ...)...), then people who have been writing
code like (lambda (ignore x ignore) (declare (ignore ignore))...)
may be upset when their code breaks.
-- Nick
∂23-Jul-86 2124 NGALL@G.BBN.COM Re: exit-to-system
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 21:24:09 PDT
Date: 24 Jul 1986 00:21-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: exit-to-system
From: NGALL@G.BBN.COM
To: gls@ZARATHUSTRA.THINK.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]24-Jul-86 00:21:19.NGALL>
In-Reply-To: <860721150138.9.GLS@BOETHIUS.THINK.COM>
Date: Mon, 21 Jul 86 15:01 EDT
From: Guy Steele <gls@Think.COM>
To: common-lisp@SU-AI.ARPA
Subject: Re: exit-to-system
In-Reply-To: <860715120338.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <860721150138.9.GLS@BOETHIUS.THINK.COM>
QUIT [Function]
This function is intended to terminate the running Lisp system in some
appropriate manner. In some implementations or under some circumstances
the Lisp system and all data contained within it may be destroyed, more
or less irretrievably, in which case the user might be left in
communication with the ``operating system'' or ``command shell,'' or
might be ``logged out.'' In other implementations or under other
circumstances this function might do nothing, in which case the call to
QUIT returns NIL (to indicate that the call ``failed'').
Sounds reasonable to me.
-- Nick
∂23-Jul-86 2126 NGALL@G.BBN.COM Re: GC function
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 21:26:00 PDT
Date: 24 Jul 1986 00:23-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: GC function
From: NGALL@G.BBN.COM
To: HASSETT%sperry-csd.csnet@RELAY.CS.NET
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]24-Jul-86 00:23:16.NGALL>
In-Reply-To: The message of Mon, 21 Jul 86 09:26 ??? from Jim Hassett <HASSETT%sperry-csd.csnet@CSNET-RELAY.ARPA>
Date: Mon, 21 Jul 86 09:26 ???
From: Jim Hassett <HASSETT%sperry-csd.csnet@CSNET-RELAY.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: GC function
The discussion concerning (GC) suggests that a major use would be to
trigger garbage collection so that delays could be avoided during some
subsequent processing, such as benchmarks or real-time operations. It
seems a bit devious to invoke garbage collection for the purpose of
preventing it, so perhaps a more direct approach to this application could
be used:
without-gc-delay form [Macro]
Evaluates form and returns what form returns, but prevents (as far as
is reasonable for the implementation) delays due to garbage collection.
It could be left up to the implementation to decide whether garbage collection
should be done before evaluating the form. Obviously, it is possible that
some forms which could otherwise be handled might exhaust available memory
when processed in this manner, unless the implementation can provide for
doing garbage collection if it can be seen to be necessary.
Does this make sense over a reasonably broad range of implementations?
Is it sufficiently useful to be included in the language?
- Jim Hassett
In my humble opinion: yes and yes.
-- Nick
∂24-Jul-86 0328 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA &BODY
Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 03:28:27 PDT
Received: from utokyo-relay by csnet-relay.csnet id ac10409; 24 Jul 86 6:32 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA00703; Thu, 24 Jul 86 13:29:05+0900
From: yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA
Received: by nttlab.ntt.junet (4.12/5.0) with TCP; Thu, 24 Jul 86 11:38:02 jst
Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet)
id AA00801; Wed, 23 Jul 86 20:10:42+0900
Date: Wed, 23 Jul 86 20:10:42+0900
Message-Id: <8607231110.AA00801@kurims.kurims.kyoto-u.junet>
To: common-lisp%SU-AI.ARPA%u-tokyo.junet@CSNET-RELAY.ARPA
Subject: &BODY
Date: Mon, 21 Jul 1986 21:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Some easy ones (?)
Message-ID: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
Proposal #6: Parsing in &BODY
Change (could conceivably break existing code which destructures &body
arguments, but this should be rare as such destructuring is generally
too complex to do via the built in mmechanism):
Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
&body (body-var [declarations-var [doc-string-var]]). If only body-var
appears in parentheses, it means the same as a body-var with no
parentheses. Otherwise, it means to give the original body to
PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is
specified) and then bind the variables to the corresponding values
returned by PARSE-BODY. This is purely a syntactic convenience for the
user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then
call PARSE-BODY himself.
Note: This extension is proposed only for &BODY, not for &REST, so &BODY
will no longer be exactly equivalent to &REST in a DEFMACRO arglist.
This is confusing. CLtL (page 146) says that
Anywhere in the lambda-list where a parameter name may appear ...,
a lambda-list may appear in place of the parameter name.
Thus, the following is a valid DEFMACRO form.
(DEFMACRO FOO (&REST (X Y Z)) ...)
which is equivalent to
(DEFMACRO FOO (X Y Z) ...)
But a similar DEFMACRO form
(DEFMACRO BAR (&BODY (X Y Z)) ...)
is regarded as
(DEFMACRO BAR (&BODY X) ...)
if doc-strings and declarations are ignored. Thus KMP's suggestion below
is less confusing.
[Note: KMP has suggested the syntax (...&body body-var decl-var doc-var).
This does not break any existing code and would allow default and
supplied-p values for the three variables. I (sef) don't think these are
important advantages, and I prefer the syntax proposed above, which is
less confusing to the eye -- my eye, ayway. The proposed format is the
one we discussed on the mailing list earlier and seemed to be favored by
most people.]
∂24-Jul-86 0653 gls@Think.COM (declare (type fixnum ---)) considered etc.
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 24 Jul 86 06:53:30 PDT
Received: from descartes by Godot.Think.COM via CHAOS; Thu, 24 Jul 86 09:53:16 edt
Date: Thu, 24 Jul 86 09:53 EDT
From: Guy Steele <gls@Think.COM>
Subject: (declare (type fixnum ---)) considered etc.
To: DLW@QUABBIN.SCRC.Symbolics.COM, gls@Think.COM, common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860723145835.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <860724095354.1.GLS@DESCARTES.THINK.COM>
Date: Wed, 23 Jul 86 14:58 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 86 12:32 EDT
From: Guy Steele <gls@Think.COM>
One thing one can say is (OR FIXNUM (SIGNED-BYTE 20)), say, which a
sufficiently clever compiler (heh, heh, heh) would understand to mean
"use a fixnum, unless fixnums are less than 20 bits, in which case use
at least 20 bits (whatever that takes)".
What is the advantage of using this instead of (SIGNED-BYTE 20)?
It feels more efficient.
Seriously, for declaring variables this probably buys you nothing.
I am guilty of somewhat fuzzy thinking. However, in the case of an
implementation that packs structs, using this type for a component
would make some sense. But I am reaching.
--Guy
∂24-Jul-86 0829 Cassels@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 24 Jul 86 08:28:53 PDT
Received: from KRYPTON.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48399; Wed 23-Jul-86 16:29:28 EDT
Date: Wed, 23 Jul 86 16:29 EDT
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: (declare (type fixnum ---)) considered etc.
To: DLW@QUABBIN.SCRC.Symbolics.COM, DCP@QUABBIN.SCRC.Symbolics.COM,
RAM@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA, Fahlman@CMU-CS-C.ARPA,
masinter.PA@XEROX.ARPA
In-Reply-To: <860723145444.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <860723162942.2.CASSELS@KRYPTON.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 86 14:54 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 86 12:42 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 1986 10:39 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
It seems that FIXNUM is no less portable than FLOAT, since nothing is
guaranteed about float exponent range and precision. A Common Lisp
program which uses floats cannot be totally portable. One could take
this as an argument against the currently system of float types, but
I don't have a better solution.
Aha! What you want is for type FLOAT to take precision and exponent
size arguments. So IEEE single-float would be (FLOAT-BINARY 24 8). We
could accept (FLOAT-DECIMAL 6 2) for those who think in base 10. )Well,
yes as a matter of fact, I did once write a PL/I program. :-(
Then you could write completely portable programs, modulo the completely
unportable ideas of rounding, size of intermediate results, etc. I
understand that there is no such thing as a completely portable
floating-point program, but this would be a step in the right direction.
Then we could move SINGLE-FLOAT, etc. to SYS: along with FIXNUM and
everyone would be happy.
(For this to become a real proposal, someone will have to figure out a
new reader syntax for floating-point constants. The current s/f/d/l
exponent mark hack depends on the current set of types.)
Good point. The difference with fixnums is that they are (a) exact and
(b) have overflow provision (into bignums).
All this means to me is that FLOAT is wrong as well. Table 2-1, page
17, specifies "recommended" minimum sizes for the floating types. I
originally argued that these should be required minimum sizes, for
exactly the reasons we're discussing here, and I still think they should
be. A "recommendation" is meaningless if you are trying to write code
and feel secure that it will run in other implementations of CL.
∂24-Jul-86 0921 @UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA Structure sharing in arguments
Received: from UR-ACORN.ARPA by SU-AI.ARPA with TCP; 24 Jul 86 09:21:43 PDT
Received: from UR-CASHEW.ARPA by UR-ACORN.ARPA via INTERNET with SMTP id 31202; 23 Jul 86 14:24:26-EDT
Date: Wed, 23 Jul 86 14:24 EDT
From: Brad Miller <miller@UR-ACORN.ARPA>
Subject: Structure sharing in arguments
To: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA
Fcc: ACORN:>miller>mail>mailout.file
In-Reply-To: <860723132120.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Supersedes: <860723142258.8.MILLER@UR-CASHEW.ARPA>
Message-ID: <860723142439.9.MILLER@UR-CASHEW.ARPA>
Return-path: <@ROCHESTER.ARPA,@SAIL.STANFORD.EDU:DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Received: from ur-cayuga.rochester.arpa (ROCHESTER.ARPA) by UR-ACORN.ARPA via INTERNET with SMTP id 31199; 23 Jul 86 13:58:36-EDT
Received: from SAIL.STANFORD.EDU (su-ai.arpa) by ur-cayuga.rochester.arpa id AA09110 (4.12w); Wed, 23 Jul 86 14:01:05 edt
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 10:21:51 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48241; Wed 23-Jul-86 13:21:25 EDT
Date: Wed, 23 Jul 86 13:21 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Structure sharing in arguments
To: hpfclp!diamant@hplabs.HP.COM, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 23 Jul 86 00:39 EDT from hpfclp!diamant@hplabs.HP.COM
Message-Id: <860723132120.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 22 Jul 86 21:39:37 pdt
From: hpfclp!diamant@hplabs.HP.COM
From: Scott Fahlman <fahlman@C.CS.CMU.EDU>
Subject: Some easy ones (?)
Proposal #13: Structure Sharing in Arguments
Clarification:
Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
Similarly, a function that takes a &REST argument should not
destructively modify it because in some implementations its top-level
list structure might share with a list that the user gave as the last
argument to APPLY.
I don't really care whether you add a restriction not to do destructive
operations on a &REST or &BODY argument, but it better be clear that the
list returned may not be something which will go away on exiting the function
(which could happen if the parameter list were stored on the stack and a
pointer to that list was returned -- apparently what Symbolics does).
Nothing currently in CLtL limits me from doing the following (nor should it):
(defun foo (&rest x) x)
(defun list (&rest list) list)
(defun copy-list (list) (apply #'list list))
[Yes, Symbolics uses stack-consed &rest lists, and they will screw you
every now and then. >>> My view of our current position <<< is that the
efficiency issues (e.g., not calling copy-list on every &rest arg) are
outweighed by the programmer resources needed to implement the copying
only when necessary.]
I'm fairly convinced that disallowing destructive operations on &rest
lists is funtionally equivalent to not being allowed to store them in
stable storage or to return them. I think my first proof caused CLtL to
dictate some aspects of function calls. I'm looking for a proof that is
within the bounds of CLtL that does have such dictations. Maybe there
aren't any. Maybe I'm wrong and they aren't equivalent, but I suspect
they are.
Now wait a second. (defun foo (&rest x) x) is not destroying the rest
argument. The problem is that the programmer who uses the result of foo
may destroy that result. Should he have to know how foo is implemented
to know what he is allowed to do to the result? I should think not....
Brad Miller
miller@rochester.arpa
miller@ur-acorn.arpa
∂24-Jul-86 0947 snyder%hplsny@hplabs.HP.COM Re: (declare (type fixnum ---)) considered etc.
Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 24 Jul 86 09:47:23 PDT
Received: from hplsny by hplabs.HP.COM ; Thu, 24 Jul 86 09:47:04 pdt
Received: by hplsny ; Thu, 24 Jul 86 09:21:35 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8607241621.AA03430@hplsny>
Date: Thu, 24 Jul 86 09:21:27 PDT
Subject: Re: (declare (type fixnum ---)) considered etc.
To: RAM@C.CS.CMU.EDU
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 23-Jul-86 15:53:00
X-Mailer: NMail [$Revision: 2.5 $]
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Subject: (declare (type fixnum ---)) considered etc.
Almost every other language in the entire world has a "INTEGER"
type which has an ill-defined, fixed precision. If Common Lisp is
going to have comparable performance to these languages when running
on the same hardware, then it is going to have to be comparably
inelegant.
Unfortunately, I must agree. I think the PL/I experience shows
that if you force people to declare the number of bits of
precision they want, in most cases they will find out what number
produces the best results on their current machine and use that,
thus making their programs non-portable in terms of efficiency.
There is no guarantee either that the maximum-array-bound
corresponds to what we think of as FIXNUMs; why shouldn't a
generous implementation allow BIGNUMs as array indexes? There
are, I admit, cases when the programmer knows how big integers
will need to be, mostly when dealing with fixed-size arrays; in
those cases, people who are concerned about efficiency should be
encouraged to declare the exact range. But, I don't think
fixed-size arrays are a particularly good idea, either. The
conventional solution is to have one or more standard integer
types with strongly suggested (required?) minimum precisions. I
think that is the right pragmatic solution to this problem, given
the desire to produce efficient code on stock architectures.
Alan
-------
∂24-Jul-86 0959 ANDY@Sushi.Stanford.EDU Re: Some easy ones (?)
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 09:59:45 PDT
Date: Thu 24 Jul 86 09:56:39-PDT
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: Re: Some easy ones (?)
To: NGALL@G.BBN.COM
cc: FREEMAN@SUMEX-AIM.Stanford.EDU, Fahlman@C.CS.CMU.EDU,
common-lisp@Sail.Stanford.EDU
In-Reply-To: <[G.BBN.COM]23-Jul-86 21:39:54.NGALL>
Message-ID: <12225270515.16.ANDY@Sushi.Stanford.EDU>
Nick (NGALL@G.BBN.COM) replied:
From: Andy Freeman <FREEMAN@SUMEX-AIM.ARPA>
Nick (NGALL@G.BBN.COM) replied to Fahlman:
Proposal #9: Variable Name Conflicts
Clarification:
Specify that it is an error for two parameters (including
supplied-p and &aux parameters) in the same lambda-list to
have the same (EQL) name.
Specify same for LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET,
MV-BIND, and PROG.
I don't know about DO*, but LET* should be able to shadow previous
names. The restriction seems reasonable for the others mentioned.
-andy
Why should LET* be able to shadow previous names when LAMBDA expressions
cannot?
-- Nick
(I'm still ignoring do*. Somebody must have an opinion.)
Let* is syntax for multiple nested lambda expressions with arguments.
The names bound by all of the other forms mentioned could conceivably
be bound by a single lambda expression (ignoring the separate function
name space). That's not true of let* (without renaming things).
Ignoring declarations for the nonce.
(let* (<b1> <b2> . <bn>)
. <body>)
is the same as
(let (<b1>)
(let* (<b2> . <bn>)
. <body>))
If let* doesn't allow duplicate names, then we'll end up writing
nested let* expressions (which is senseless, let* was invented to
avoid nested let expressions) or using setq more than necessary.
Why do you object to duplicate names in let*?
-andy
-------
∂24-Jul-86 1011 ALR%OZ.AI.MIT.EDU@AI.AI.MIT.EDU REDUCE args
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 10:11:25 PDT
Date: Thu, 24 Jul 1986 13:11 EDT
Message-ID: <ALR.12225273192.BABYL@MIT-OZ>
From: ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: common-lisp@SU-AI.ARPA
Subject: REDUCE args
In-reply-to: Msg of 24 Jul 1986 00:23-EDT from NGALL at G.BBN.COM
Does anybody else wish that REDUCE took a KEY argument, similarly to MEMBER.
i.e.
(reduce #'+ list-of-objects :KEY #'object-quantity)
would apply the function OBJECT-QUANTITY to each element of the
list-of-objects before reducing it with +.
Andrew
∂24-Jul-86 1026 shebs%utah-orion@utah-cs.arpa Re: (declare (type fixnum ---)) considered etc.
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 10:26:11 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA12728; Thu, 24 Jul 86 11:26:16 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA01726; Thu, 24 Jul 86 11:26:12 MDT
Date: Thu, 24 Jul 86 11:26:12 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8607241726.AA01726@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: (declare (type fixnum ---)) considered etc.
Summary:
Expires:
References: <860723162942.2.CASSELS@KRYPTON.SCRC.Symbolics.COM>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <860723162942.2.CASSELS@KRYPTON.SCRC.Symbolics.COM> Cassels@STONY-BROOK.SCRC.Symbolics.COM (Robert A. Cassels) writes:
>Aha! What you want is for type FLOAT to take precision and exponent
>size arguments. So IEEE single-float would be (FLOAT-BINARY 24 8). We
>could accept (FLOAT-DECIMAL 6 2) for those who think in base 10. )Well,
>yes as a matter of fact, I did once write a PL/I program. :-(
I think this is a GREAT idea. (the type specifier, not the PL/I :-)
>[...]
>Then we could move SINGLE-FLOAT, etc. to SYS: along with FIXNUM and
>everyone would be happy.
>
>(For this to become a real proposal, someone will have to figure out a
>new reader syntax for floating-point constants. The current s/f/d/l
>exponent mark hack depends on the current set of types.)
Well, since elaborating the FLOAT type increases the size of the language,
we should counteract that by flushing s/f/d/l, retaining only e for the
exponent marker, and use *read-default-float-format*. To avoid having to
rebind this global for just one read, use #F. For instance, you could
handle .1003l45 as #69,23F(1003 45). It's more longwinded, true, but
is considerably more precise and therefore more portable. Depends on how
determined we are to retain total compatibility with Fortran syntaxes
that were invented 30 years ago I guess...
On the other hand, this proposal logically requires bigfloats, otherwise
you have to have a maximum-mantissa-size parameter etc for each CL, and
if somebody's Cray program wants 240 bit mantissas, they're not going to have
much luck on Vaxen. Bigfloats don't bother me - they would win just like
bignums do now.
stan
∂24-Jul-86 1037 DCP@QUABBIN.SCRC.Symbolics.COM Re: (declare (type fixnum ---)) considered etc.
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 10:36:31 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23567; Thu 24-Jul-86 13:35:30 EDT
Date: Thu, 24 Jul 86 13:34 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: (declare (type fixnum ---)) considered etc.
To: Alan Snyder <snyder%hplsny@HPLABS.HP.COM>, RAM@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8607241621.AA03430@hplsny>
Message-ID: <860724133427.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 24 Jul 86 09:21:27 PDT
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Subject: (declare (type fixnum ---)) considered etc.
Almost every other language in the entire world has a "INTEGER"
type which has an ill-defined, fixed precision. If Common Lisp is
going to have comparable performance to these languages when running
on the same hardware, then it is going to have to be comparably
inelegant.
(signed-byte 69). What's inefficient about that kind of construct. The
problem with those other languages is that you CAN'T write realiable
portable code that is depending on those "integers" In yonger days, I
would have wanted PDP-11 fortran to overflow "integers" into "bignums".
No such luck. CL is considerably more powerful than those other
languages, and still provides the necessary constructs to give hints to
the compiler. (signed-byte 12) is a perfectly valid thing. It
CORRECTLY reflects the intent of the programmer, AND is portable.
FIXNUM does neither of these.
Unfortunately, I must agree. I think the PL/I experience shows
that if you force people to declare the number of bits of
precision they want, in most cases they will find out what number
produces the best results on their current machine and use that,
thus making their programs non-portable in terms of efficiency.
I pity the minds of those programmers. If they are writing
system-dependent architecture-dependent code, fine. If they are writing
portable code, they MUST declare their intents to get reasonable
efficiency from a variety of systems.
There is no guarantee either that the maximum-array-bound
corresponds to what we think of as FIXNUMs; why shouldn't a
generous implementation allow BIGNUMs as array indexes? There
are, I admit, cases when the programmer knows how big integers
will need to be, mostly when dealing with fixed-size arrays; in
those cases, people who are concerned about efficiency should be
encouraged to declare the exact range. But, I don't think
fixed-size arrays are a particularly good idea, either. The
conventional solution is to have one or more standard integer
types with strongly suggested (required?) minimum precisions. I
think that is the right pragmatic solution to this problem, given
the desire to produce efficient code on stock architectures.
If you really want to go least-common-denominator, you will probably
have to settle for 7 guarenteed bits, or maybe 8 or 9; I can't remember
how big MacLisp fixnums are.
∂24-Jul-86 1043 NGALL@G.BBN.COM Re: REDUCE args
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 10:43:08 PDT
Date: 24 Jul 1986 13:39-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: REDUCE args
From: NGALL@G.BBN.COM
To: ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]24-Jul-86 13:39:15.NGALL>
In-Reply-To: <ALR.12225273192.BABYL@MIT-OZ>
Date: Thu, 24 Jul 1986 13:11 EDT
From: ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: common-lisp@SU-AI.ARPA
Subject: REDUCE args
In-Reply-To: Msg of 24 Jul 1986 00:23-EDT from NGALL at G.BBN.COM
Message-ID: <ALR.12225273192.BABYL@MIT-OZ>
Does anybody else wish that REDUCE took a KEY argument, similarly to MEMBER.
i.e.
(reduce #'+ list-of-objects :KEY #'object-quantity)
would apply the function OBJECT-QUANTITY to each element of the
list-of-objects before reducing it with +.
Andrew
--------------------
YES! I ran into the same need a while back.
-- Nick
∂24-Jul-86 1050 shebs%utah-orion@utah-cs.arpa Re: (declare (type fixnum ---)) considered etc.
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 10:47:41 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA13145; Thu, 24 Jul 86 11:47:51 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA01815; Thu, 24 Jul 86 11:47:47 MDT
Date: Thu, 24 Jul 86 11:47:47 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8607241747.AA01815@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: (declare (type fixnum ---)) considered etc.
Summary:
Expires:
References: <8607241621.AA03430@hplsny>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <8607241621.AA03430@hplsny> snyder%hplsny@hplabs.HP.COM (Alan Snyder) writes:
>I think the PL/I experience shows
>that if you force people to declare the number of bits of
>precision they want, in most cases they will find out what number
>produces the best results on their current machine and use that,
>thus making their programs non-portable in terms of efficiency.
This is a red herring. Almost everything in CL is going to vary
in efficiency between implementations. Consider FUNCALL - some impls
do it almost as well as a direct call, while others cons up a list
of arguments and feed to APPLY. This has a direct bearing on the
efficiency of using things like MEMBER's keyword arguments. Consider
generic sequence functions, whose allowed variation is notorious;
DELETE is not even required to be destructive! Consider arrays, which
can be specialized in a dozen ways, or not at all.
As a language, Common Lisp can promise consistent efficiency or consistent
behavior - and I prefer the latter. It might be possible to promise both in
a high-level language, but nobody's succeeded yet...
stan
∂24-Jul-86 1100 DCP@QUABBIN.SCRC.Symbolics.COM Re: Some easy ones (?)
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 10:58:54 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23580; Thu 24-Jul-86 13:58:03 EDT
Date: Thu, 24 Jul 86 13:58 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Some easy ones (?)
To: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA
cc: Fahlman@C.CS.CMU.EDU
In-Reply-To: <[G.BBN.COM]23-Jul-86 22:27:40.NGALL>
Message-ID: <860724135811.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 23 Jul 1986 22:27-EDT
From: NGALL@G.BBN.COM
Date: Wed, 23 Jul 86 13:08 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
To: NGALL@G.BBN.COM, Fahlman@C.CS.CMU.EDU
Subject: Re: Some easy ones (?)
In-Reply-To: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>
Message-ID: <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 23 Jul 1986 02:30-EDT
From: NGALL@G.BBN.COM
Taking into account the other comments on this function (the ones that
I agree with at least), how about this proposal
(PARSE-BODY body &optional environment
declarations-allowed-p
doc-string-allowed-p)
Parses a BODY argument of the form
({declaration|doc-string}* {form}*)
...
Until somebody says something profound to change my mind, I hold that if
a "body" may not contain either declarations or doc-strings, it is not a
true body, and therefore you have no right to call PARSE-BODY. I have
no idea what the reference to CASE and PROGN was. If the claim that
each clause of a CASE contained a "body" you are wrong; it contains an
"implicit PROGN". Implicit PROGNs are not suitable arguments to
PARSE-BODY.
This may not be profound, but its true. A robust macro definition of
CASE, i.e., one that performs an expansion time check to ensure that
the initial forms after the KEYFORM are not declarations, can be
written much more easily with DECLARATIONS-ALLOWED-P, e.g.,
(defmacro case (keyform &rest clauses &environment env)
(multiple-value-bind (decls doc clauses)
(parse-body clauses env nil)
(declare (ignore decls doc))
;; At this point I can rest assured that parse-body has detected
;; any illegal declarations.
...)
Congradulations, you just broke CASE. Three things: First, you are
calling parse-body on an &REST. The is semantically 100% incorrect.
Second, this form won't work:
(case foo
(declare (print "FOO's value was DECLARE"))
(otherwise (print "FOO's value was not DECLARE")))
Third, this breaks worse
(macrolet ((uncalled-macro (&rest ignore)
(error "Loser!!")))
(case foo
(uncalled-macro (print "FOO's value was UNCALLED-MACRO"))
(otherwise (print "FOO's value was something else"))))
I think both are obvious.
Things are easier still if we adopt my proposal for &body:
(defmacro case (keyform &body (&forms clauses))
;; At this point I can rest assured that parse-body has detected
;; any illegal declarations.
...)
Profound enough?
Wrong again. (Adding complex syntax doesn't help, either.) They aren't
forms. They are case clauses. Here's the full syntactic definition of
case, I think (it differs slightly from page 117):
(case
{ ( { atom-not-t-nil-otherwise | ( {atom}* ) }
. implicit-progn ) }*
{ nothing | ( { otherwise | t }
. implicit-progn ) }
)
There is no body in here what-so-ever. Therefore, parse-body is
conceptually the wrong thing. Maybe what you want is something called
VERIFY-IMPLICIT-PROGN? The contract of this is to make sure there
aren't any declarations?
∂24-Jul-86 1101 Cassels@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 24 Jul 86 11:00:40 PDT
Received: from KRYPTON.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49027; Thu 24-Jul-86 13:59:35 EDT
Date: Thu, 24 Jul 86 13:59 EDT
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: (declare (type fixnum ---)) considered etc.
To: RAM@C.CS.CMU.EDU, Cassels@STONY-BROOK.SCRC.Symbolics.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12225040519.BABYL@C.CS.CMU.EDU>
Message-ID: <860724135953.1.CASSELS@KRYPTON.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 1986 15:53 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Almost every other language in the entire world has a "INTEGER"
type which has an ill-defined, fixed precision. If Common Lisp is
going to have comparable performance to these languages when running
on the same hardware, then it is going to have to be comparably
inelegant.
This argument is somewhat confused. There are two conflicting goals
being pursued by the CL community. One is to have portable programs.
The other is to have good performance on the particular implementation
you're using. There is no way to write programs which simultaneously
satisfy both goals. The best we can do as language designers is to
provide mechanisms which allow both to be achieved. Ideally, we can
provide a range of options to users so they can choose their own balance
between performance and portability. As a service to our users, we can
help them understand how to achieve either goal.
What "INTEGER" originally meant (in Fortran, for example) was, "the
biggest precision available on the machine". Recently C and other
languages modified that slightly to be, "a reasonably big precision
which is still reasonably fast and doesn't take up too much space."
Many languages, like Pascal, provide (in addition to the fuzzy,
machine-dependent precisions) user-specified ranges or precisions.
These allow portable programs to be written which will be optimized to
be as fast as they can be on the particular machine.
Common Lisp provides for both kinds of declarations. What's different
is that CL type "INTEGER" is defined to be arbitrary precision -- a
concept that traditional languages don't have. In those languages, you
don't get the option of truly portable programs.
I didn't say we shouldn't have type FIXNUM. I said we should put it
somewhere where it would be obvious that programs using it are probably
not portable.
Programmers who declare objects of type FIXNUM are just being sloppy.
If their goal is to make portable, fast programs, they'll figure out
what the range really is and tell the compiler. If the range can't be
figured out, then telling the compiler that it's a FIXNUM is lie. (If
you don't care about portability and your program works, it's a
convenient lie.) If you want the freedom to be sloppy, or you really
can't limit the range, you must either pay the price of reduced
performance or buy a machine which doesn't need declarations to get
performance. [I never use type declarations in my CL programs.]
∂24-Jul-86 1130 RAM@C.CS.CMU.EDU (declare (type fixnum ---)) considered etc.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 11:28:48 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 24 Jul 86 14:28:42-EDT
Date: Thu, 24 Jul 1986 14:28 EDT
Message-ID: <RAM.12225287225.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: (declare (type fixnum ---)) considered etc.
In-reply-to: Msg of 24 Jul 1986 13:59-EDT from Robert A. Cassels <Cassels at STONY-BROOK.SCRC.Symbolics.COM>
Date: Thursday, 24 July 1986 13:59-EDT
From: Robert A. Cassels <Cassels at STONY-BROOK.SCRC.Symbolics.COM>
Re: (declare (type fixnum ---)) considered etc.
If you want the freedom to be sloppy, or you really
can't limit the range, you must either pay the price of reduced
performance or buy a machine which doesn't need declarations to get
performance. [I never use type declarations in my CL programs.]
I don't think we should have people who never use type declarations
telling those of us who do what kind of declarations we can and can't
use. Nor do I think a company should change Common Lisp so that
everyone has to buy their machines to run fast.
I'm getting tired of this discussion. Why doesn't everyone just admit
we aren't going to get agreement on this issue. The split seems to be
drawn largely along special-hardware/standard-hardware lines, and
neither community is going to go away. In any case, flushing the
fixnum declaration is not one of the proposals we are supposed to be
discussing. If it were, it would be unlikely to pass, since under the
criteria for changes, approval would have to be near-unanimous, which
it isn't.
Rob
∂24-Jul-86 1133 DCP@QUABBIN.SCRC.Symbolics.COM Structure sharing in arguments
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 11:28:58 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23588; Thu 24-Jul-86 14:16:19 EDT
Date: Thu, 24 Jul 86 14:16 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Structure sharing in arguments
To: Brad Miller <miller@UR-ACORN.ARPA>,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860723142439.9.MILLER@UR-CASHEW.ARPA>
Message-ID: <860724141621.4.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 86 14:24 EDT
From: Brad Miller <miller@UR-ACORN.ARPA>
Return-path: <@ROCHESTER.ARPA,@SAIL.STANFORD.EDU:DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM>
Received: from ur-cayuga.rochester.arpa (ROCHESTER.ARPA) by UR-ACORN.ARPA via INTERNET with SMTP id 31199; 23 Jul 86 13:58:36-EDT
Received: from SAIL.STANFORD.EDU (su-ai.arpa) by ur-cayuga.rochester.arpa id AA09110 (4.12w); Wed, 23 Jul 86 14:01:05 edt
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 10:21:51 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48241; Wed 23-Jul-86 13:21:25 EDT
Date: Wed, 23 Jul 86 13:21 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Structure sharing in arguments
To: hpfclp!diamant@hplabs.HP.COM, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 23 Jul 86 00:39 EDT from hpfclp!diamant@hplabs.HP.COM
Message-Id: <860723132120.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 22 Jul 86 21:39:37 pdt
From: hpfclp!diamant@hplabs.HP.COM
From: Scott Fahlman <fahlman@C.CS.CMU.EDU>
Subject: Some easy ones (?)
Proposal #13: Structure Sharing in Arguments
Clarification:
Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
Similarly, a function that takes a &REST argument should not
destructively modify it because in some implementations its top-level
list structure might share with a list that the user gave as the last
argument to APPLY.
I don't really care whether you add a restriction not to do destructive
operations on a &REST or &BODY argument, but it better be clear that the
list returned may not be something which will go away on exiting the function
(which could happen if the parameter list were stored on the stack and a
pointer to that list was returned -- apparently what Symbolics does).
Nothing currently in CLtL limits me from doing the following (nor should it):
(defun foo (&rest x) x)
(defun list (&rest list) list)
(defun copy-list (list) (apply #'list list))
[Yes, Symbolics uses stack-consed &rest lists, and they will screw you
every now and then. >>> My view of our current position <<< is that the
efficiency issues (e.g., not calling copy-list on every &rest arg) are
outweighed by the programmer resources needed to implement the copying
only when necessary.]
I'm fairly convinced that disallowing destructive operations on &rest
lists is funtionally equivalent to not being allowed to store them in
stable storage or to return them. I think my first proof caused CLtL to
dictate some aspects of function calls. I'm looking for a proof that is
within the bounds of CLtL that does have such dictations. Maybe there
aren't any. Maybe I'm wrong and they aren't equivalent, but I suspect
they are.
Now wait a second. (defun foo (&rest x) x) is not destroying the rest
argument. The problem is that the programmer who uses the result of foo
may destroy that result. Should he have to know how foo is implemented
to know what he is allowed to do to the result? I should think not....
Precisely. Now consider this. What is the difference between FOO being
destructive on X and the caller of FOO being destructive on the result.
Are not the X that FOO sees and the result that FOO returns EQL? I
should hope so! This means you can't copy-if-return or
copy-if-stable-store. (There are harder issues about passing it to
other functions.) Therefore, if you let the caller of FOO be
destructive on the result of FOO (your premise which I agree with), you
have to let FOO be destructive on X. In other words, the proposal
(repeated here)
Similarly, a function that takes a &REST argument should not
destructively modify it because in some implementations its top-level
list structure might share with a list that the user gave as the last
argument to APPLY.
simply doesn't hold water. The only way out of this I can see is that
if an &REST arg cannot be proven to be used in only a "downward" fashion
(i.e., it nor any tail is returned or stored in stable storage), then it
must always be a freshly consed list.
Let's see if I can summarize this line of thought. Requiring
implementations to be non-destructive on their &REST arg implies
non-local knowledge by the callers. This isn't good, and therefore
discarded. Therefore, we should allow destructive operations on &REST
args.
∂24-Jul-86 1206 STEVER%OZ.AI.MIT.EDU@AI.AI.MIT.EDU Declaration before variable
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 11:58:06 PDT
Date: Thu, 24 Jul 1986 14:44 EDT
Message-ID: <STEVER.12225290155.BABYL@MIT-OZ>
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
to: common-lisp@SU-AI.ARPA
Subject: Declaration before variable
In-reply-to: Msg of 23 Jul 1986 22:01-EDT from NGALL at G.BBN.COM
Date: Wednesday, 23 July 1986 22:01-EDT
From: NGALL at G.BBN.COM
Date: 23 Jul 1986 1252-PDT
From: Rem@IMSSS
Perhaps LISP should do this:
(DEFUN (STRING FOO) ((INTEGER X1 X2) (STRING S) (REAL Z))
...)
I would love such a declaration scheme.
Having used languages which do this kind of declaring, I third
the proposal.
-- Stever
∂24-Jul-86 1219 DCP@QUABBIN.SCRC.Symbolics.COM Re: REDUCE args
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 12:00:24 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23631; Thu 24-Jul-86 14:59:22 EDT
Date: Thu, 24 Jul 86 14:59 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: REDUCE args
To: NGALL@G.BBN.COM, ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]24-Jul-86 13:39:15.NGALL>
Message-ID: <860724145929.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 24 Jul 1986 13:39-EDT
From: NGALL@G.BBN.COM
Date: Thu, 24 Jul 1986 13:11 EDT
From: ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: common-lisp@SU-AI.ARPA
Subject: REDUCE args
In-Reply-To: Msg of 24 Jul 1986 00:23-EDT from NGALL at G.BBN.COM
Message-ID: <ALR.12225273192.BABYL@MIT-OZ>
Does anybody else wish that REDUCE took a KEY argument, similarly to MEMBER.
i.e.
(reduce #'+ list-of-objects :KEY #'object-quantity)
would apply the function OBJECT-QUANTITY to each element of the
list-of-objects before reducing it with +.
Andrew
--------------------
YES! I ran into the same need a while back.
Ditto. I think GLS made some comment about this usage of :KEY being
different than most. Maybe that was in a different discussion. There
are possibly other related operations that should take KEY. One could
also add :TEST to avoid calling the operator on objects you don't want
to. Maybe this was Steele's point: Does the key apply before or after
the test? I think the intuitive usage is backwards from the other
usages.
∂24-Jul-86 1321 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: (declare (type fixnum ---)) considered etc.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 24 Jul 86 12:49:09 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49168; Thu 24-Jul-86 15:47:48 EDT
Date: Thu, 24 Jul 86 15:49 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: (declare (type fixnum ---)) considered etc.
To: snyder%hplsny@hplabs.HP.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8607241621.AA03430@hplsny>
Message-ID: <860724154914.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 24 Jul 86 09:21:27 PDT
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Unfortunately, I must agree. I think the PL/I experience shows
that if you force people to declare the number of bits of
precision they want, in most cases they will find out what number
produces the best results on their current machine and use that,
thus making their programs non-portable in terms of efficiency.
I'm not sure what universal "the PL/I experience" you mean. Apparently
you have observed PL/I programmers who did not use PL/I's declarations
in order to achieve portability. That's hardly surprising. Most PL/I
programmers are not even aware that the world contains computers that
are not IBM System 370's. No matter how many PL/I programmers out there
don't care about portability, Common Lisp is a different story, and we
should provide a language definition aimed at allowing programs to be
portable.
There is no guarantee either that the maximum-array-bound
corresponds to what we think of as FIXNUMs; why shouldn't a
generous implementation allow BIGNUMs as array indexes?
(Actually, I never understood why array indexes were in any way
specifically tied to FIXNUMs. This seems arbitrary and pragmatic but
not in the spirit of portability.)
There
are, I admit, cases when the programmer knows how big integers
will need to be, mostly when dealing with fixed-size arrays; in
those cases, people who are concerned about efficiency should be
encouraged to declare the exact range.
Is that the only occasion you can imagine in which one might know an
upper bound on the value of an integer-valued variable? If so, then in
all other cases, the FIXNUM declaration is useless because the number
might be a bignum. But I don't think that's really so.
But, I don't think
fixed-size arrays are a particularly good idea, either. The
conventional solution is to have one or more standard integer
types with strongly suggested (required?) minimum precisions. I
think that is the right pragmatic solution to this problem, given
the desire to produce efficient code on stock architectures.
I don't see how "strongly suggested" precisions do any good at all.
They let us say "I guarantee that this program will probably run"? What
does that mean? What's the difference between a "strong" and "weak"
suggestion? Does "strongly suggested" mean "it's not required, but if
you don't implement it, programs won't necessary work properly", and if
so, how is that different from a requirement? "I strongly recommend
that you implement APPEND; it's not required, but some programs will not
port to your implementation...".
Required minimum precisions could be done, but I see no advantage over
just using the parameterized INTEGER declaration. Having a few standard
types with required minimum precisions is just like the parameterized
INTEGER declaration except that you only allow a few specific values for
the parameter. I don't see how that buys anything, and in some cases it
will result in overkill since you have to ask for slightly more than you
need. As I said earlier, it's trivial for a compiler to take a request
for "at least N bits", and round up to the next available size provided
by the hardware. (When I speak of "bits" I really mean "ranges", since
not all computers are binary etc., but you know what I mean.)
∂24-Jul-86 1244 @UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA Re: REDUCE args
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 12:26:02 PDT
Received: from UR-CASHEW.ARPA by UR-ACORN.ARPA via INTERNET with SMTP id 31285; 24 Jul 86 15:21:30-EDT
Date: Thu, 24 Jul 86 15:21 EDT
From: Brad Miller <miller@UR-ACORN.ARPA>
Subject: Re: REDUCE args
To: NGALL@BBNCCG.ARPA
cc: ALR%OZ.AI.MIT.EDU@MIT-XX.ARPA, common-lisp@SU-AI.ARPA
Fcc: ACORN:>miller>mail>mailout.file
In-Reply-To: <[G.BBN.COM]24-Jul-86 13:39:15.NGALL>
Message-ID: <860724152140.0.MILLER@UR-CASHEW.ARPA>
Date: 24 Jul 1986 13:39-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: REDUCE args
From: NGALL@G.BBN.COM
To: ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Cc: common-lisp@SU-AI.ARPA
Message-Id: <[G.BBN.COM]24-Jul-86 13:39:15.NGALL>
In-Reply-To: <ALR.12225273192.BABYL@MIT-OZ>
Date: Thu, 24 Jul 1986 13:11 EDT
From: ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: common-lisp@SU-AI.ARPA
Subject: REDUCE args
In-Reply-To: Msg of 24 Jul 1986 00:23-EDT from NGALL at G.BBN.COM
Message-ID: <ALR.12225273192.BABYL@MIT-OZ>
Does anybody else wish that REDUCE took a KEY argument, similarly to MEMBER.
i.e.
(reduce #'+ list-of-objects :KEY #'object-quantity)
would apply the function OBJECT-QUANTITY to each element of the
list-of-objects before reducing it with +.
Andrew
--------------------
YES! I ran into the same need a while back.
-- Nick
I third it. A good hack.
Brad Miller
∂24-Jul-86 1244 SCHERLIS@C.CS.CMU.EDU Lisp Conference, continued
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 12:22:31 PDT
Received: ID <SCHERLIS@C.CS.CMU.EDU>; Thu 24 Jul 86 15:22:18-EDT
Date: Thu 24 Jul 86 15:22:16-EDT
From: Bill.Scherlis@C.CS.CMU.EDU
Subject: Lisp Conference, continued
To: common-lisp@SU-AI.ARPA
Message-ID: <12225297024.25.SCHERLIS@C.CS.CMU.EDU>
It appears that a number of people who should have received conference
brochures for the Lisp Conference from the ACM did not in fact receive
them. To help the ACM debug their procedures and to prevent recurrences
of this lossage I need to collect some information. So:
IF (1) You are an ACM member;
(2) You are a member of at least one of SIGACT, SIGART,
SIGPLAN; and
(3) You did NOT receive the conference brochure directly
from the ACM.
THEN please respond to Marce Zaragoza (Zaragoza@c.cs.cmu.edu)
with the following information:
(1) Your name as it appears on ACM mailing labels.
(2) A list of the SIGs you are a member of.
You should respond even if you previously sent her a message requesting
a copy of the brochure. Please respond as soon as possible. Thanks.
-------
∂24-Jul-86 1402 FAHLMAN@C.CS.CMU.EDU REDUCE args
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 13:22:11 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 24 Jul 86 16:22:19-EDT
Date: Thu, 24 Jul 1986 16:22 EDT
Message-ID: <FAHLMAN.12225307944.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: REDUCE args
In-reply-to: Msg of 24 Jul 1986 14:59-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
OK, I'll add REDUCE :KEY to the list of things to discuss later. We've
got enough going just now.
-- Scott
∂24-Jul-86 1402 NGALL@G.BBN.COM Re: Lisp Conference, continued
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 13:48:33 PDT
Date: 24 Jul 1986 16:44-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Lisp Conference, continued
From: NGALL@G.BBN.COM
To: Zaragoza@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]24-Jul-86 16:44:56.NGALL>
In-Reply-To: <12225297024.25.SCHERLIS@C.CS.CMU.EDU>
Date: Thu 24 Jul 86 15:22:16-EDT
From: Bill.Scherlis@C.CS.CMU.EDU
To: common-lisp@SU-AI.ARPA
Subject: Lisp Conference, continued
Message-ID: <12225297024.25.SCHERLIS@C.CS.CMU.EDU>
It appears that a number of people who should have received conference
brochures for the Lisp Conference from the ACM did not in fact receive
them. To help the ACM debug their procedures and to prevent recurrences
of this lossage I need to collect some information. So:
IF (1) You are an ACM member;
(2) You are a member of at least one of SIGACT, SIGART,
SIGPLAN; and
(3) You did NOT receive the conference brochure directly
from the ACM.
THEN please respond to Marce Zaragoza (Zaragoza@c.cs.cmu.edu)
with the following information:
(1) Your name as it appears on ACM mailing labels.
(2) A list of the SIGs you are a member of.
You should respond even if you previously sent her a message requesting
a copy of the brochure. Please respond as soon as possible. Thanks.
-------
--------------------
(1) NICHOLAS L GALL
(2) SIGART and SIGPLAN
∂24-Jul-86 1539 edsel!bhopal!jonl@navajo.stanford.edu UNSPECIAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 15:17:26 PDT
Received: by navajo.stanford.edu; Thu, 24 Jul 86 15:16:05 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA21757; Thu, 24 Jul 86 14:52:13 pdt
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA07606; Thu, 24 Jul 86 14:57:32 PDT
Date: Thu, 24 Jul 86 14:57:32 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8607242157.AA07606@bhopal.edsel.uucp>
To: navajo!common-lisp%su-ai@navajo.stanford.edu
Subject: UNSPECIAL
I meant PROCLAIM UNSPECIAL rather than DECLARE UNSPECIAL
Jonl
∂24-Jul-86 1539 DSinger@SRI-KL.ARPA The (not special) declaration
Received: from SRI-KL.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 15:37:35 PDT
Date: Thu 24 Jul 86 13:41:33-PDT
From: David Singer <DSinger@SRI-KL>
Subject: The (not special) declaration
To: common-lisp%SU-AI@SRI-KL
Really this should be there, on grounds of completeness if nothing else.
(1) CommonLisp claims to be primarily lexically scoped, but there is no
way to declare the type of a variable such that it is lexically scoped;
(it is unusual to find a construct with a default behaviour which you
cannot explicitly state);
(2) espcially I cannot hide the effect of a PROCLAIM SPECIAL anywhere,
because of the lack of a (NOT SPECIAL) type;
(3) which is serious, because the 'obvious' way to declare a global is to
use DEFVAR, which uses PROCLAIM SPECIAL. Why is the 'normal' global
variable construct in a lexically scoped lisp proclaimed special?
(You can of course get a lexical global effectively by using a top-level
SETQ, and then declaring special in just those forms where you want
to access the global. But setq is not really a 'declaration', and it is
at least odd to find a lexical-scope language with no lexical-global
declaration).
Personally I like the suggestion to include a LOCAL specifier; (I also like
the suggestion to be allowed to declare types where most other languages
do, i.e. with first mention, like in defun argument lists
(defun fred (integer foo) ...); I have been bitten by the current rules,
and the new ones are an improvement but nowhere near as automatically
intuitive as say algol. Yes, I think it was a mistake to mix lexical
and special variables in the same language constructs).
-------
∂24-Jul-86 1543 NGALL@G.BBN.COM Re: Some easy ones (?)
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 12:37:41 PDT
Date: 24 Jul 1986 15:29-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Some easy ones (?)
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Cc: Fahlman@C.CS.CMU.EDU
Message-ID: <[G.BBN.COM]24-Jul-86 15:29:46.NGALL>
In-Reply-To: <860724135811.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Thu, 24 Jul 86 13:58 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
To: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA
Subject: Re: Some easy ones (?)
In-Reply-To: <[G.BBN.COM]23-Jul-86 22:27:40.NGALL>
Message-ID: <860724135811.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 23 Jul 1986 22:27-EDT
From: NGALL@G.BBN.COM
Date: Wed, 23 Jul 86 13:08 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
To: NGALL@G.BBN.COM, Fahlman@C.CS.CMU.EDU
Subject: Re: Some easy ones (?)
In-Reply-To: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>
Message-ID: <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 23 Jul 1986 02:30-EDT
From: NGALL@G.BBN.COM
Taking into account the other comments on this function (the ones that
I agree with at least), how about this proposal
(PARSE-BODY body &optional environment
declarations-allowed-p
doc-string-allowed-p)
Parses a BODY argument of the form
({declaration|doc-string}* {form}*)
...
Until somebody says something profound to change my mind, I hold that if
a "body" may not contain either declarations or doc-strings, it is not a
true body, and therefore you have no right to call PARSE-BODY. I have
no idea what the reference to CASE and PROGN was. If the claim that
each clause of a CASE contained a "body" you are wrong; it contains an
"implicit PROGN". Implicit PROGNs are not suitable arguments to
PARSE-BODY.
This may not be profound, but its true. A robust macro definition of
CASE, i.e., one that performs an expansion time check to ensure that
the initial forms after the KEYFORM are not declarations, can be
written much more easily with DECLARATIONS-ALLOWED-P, e.g.,
(defmacro case (keyform &rest clauses &environment env)
(multiple-value-bind (decls doc clauses)
(parse-body clauses env nil)
(declare (ignore decls doc))
;; At this point I can rest assured that parse-body has detected
;; any illegal declarations.
...)
Congradulations, you just broke CASE. Three things: First, you are
calling parse-body on an &REST. The is semantically 100% incorrect.
Second, this form won't work:
(case foo
(declare (print "FOO's value was DECLARE"))
(otherwise (print "FOO's value was not DECLARE")))
Third, this breaks worse
(macrolet ((uncalled-macro (&rest ignore)
(error "Loser!!")))
(case foo
(uncalled-macro (print "FOO's value was UNCALLED-MACRO"))
(otherwise (print "FOO's value was something else"))))
I think both are obvious.
Yes they are. Sorry I didn't see them.
Things are easier still if we adopt my proposal for &body:
(defmacro case (keyform &body (&forms clauses))
;; At this point I can rest assured that parse-body has detected
;; any illegal declarations.
...)
Profound enough?
Wrong again. (Adding complex syntax doesn't help, either.) They aren't
forms. They are case clauses. Here's the full syntactic definition of
case, I think (it differs slightly from page 117):
(case
{ ( { atom-not-t-nil-otherwise | ( {atom}* ) }
. implicit-progn ) }*
{ nothing | ( { otherwise | t }
. implicit-progn ) }
)
There is no body in here what-so-ever. Therefore, parse-body is
conceptually the wrong thing. Maybe what you want is something called
VERIFY-IMPLICIT-PROGN? The contract of this is to make sure there
aren't any declarations?
Yes. PARSE-BODY called with DECLARATIONS-ALLOWED-P of NIL would be
used to verify that an implicit PROGN does not begin with decls (it
could be used with 'bodies' other than implicit PROGNs, but only if
such bodies do not allow a declaration-like syntax (unlike CASE and
COND (boy, did I pick a bad example!)).
Yes. Its contract would be to make sure there aren't any declarations.
This was the point I was trying (and failing so miserably) to make.
-- Nick
∂24-Jul-86 1543 DSinger@SRI-KL.ARPA without-gc-delay
Received: from SRI-KL.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 12:36:57 PDT
Date: Thu 24 Jul 86 08:36:09-PDT
From: David Singer <DSinger@SRI-KL>
Subject: without-gc-delay
To: common-lisp%SU-AI@SRI-KL
Why not cover the ground and call it:
without-system-delay
Evaluates form and returns what that form returns, but prevents (as far as
is reasonable for the implementation) delays due to periodic system
activity not normally under the control of the user (for example, garbage
collection).
Note: a common use of without-system-delay is with an embedded time form,
to obtain reasonably consistent timings without the impact of
major systems activity.
(The reason I extend the name is because of systems which perform periodic
housekeeping for e.g. network and file-system management, which can usually
be delayed).
-------
∂24-Jul-86 1547 DSinger@SRI-KL.ARPA Case of symbols and their print-names
Received: from SRI-KL.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 12:38:55 PDT
Date: Thu 24 Jul 86 10:05:49-PDT
From: David Singer <DSinger@SRI-KL>
Subject: Case of symbols and their print-names
To: common-lisp%SU-AI@SRI-KL
I agree with the common-lisp decision to equate case; what I do not like
is the decision to upper-case on input. I would much prefer it if the
print-name of a symbol was maintained in the case in which it was first
presented, even if for symbol-searching/matching/internal purposes, an
upper-case string is also recorded. Then print functions can output
the mixed-case print-name (without escape characters, to preserve
print-read consistency). Without this, editors which behave like
interlisp Dedit will be unpleasant, because they'll upper-case your
programs for presentation back to you.
-------
∂24-Jul-86 1549 FAHLMAN@C.CS.CMU.EDU FIXNUM considered useful
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 14:38:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 24 Jul 86 17:38:21-EDT
Date: Thu, 24 Jul 1986 17:38 EDT
Message-ID: <FAHLMAN.12225321784.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: FIXNUM considered useful
The language as it stands provides a perfectly good mechanism for people
who want to specify the range of certain integers in a strictly portable
way. It also provides the more convenient FIXNUM declaration for people
who want to use that. Like many constructs in the language, the latter
is implementation-dependent in certain ways that are carefully spelled
out (though not in the optimal place in the manual -- that will be
fixed).
I see no need to remove FIXNUM declarations from the language. I
promise to convert all (FIXNUM foo) declarations to (INTEGER foo) in any
code I send to Xerox and Symbolics in the future, or to explain to them
how they can do this themselves using the wonders of modern editor
technology. Our code has a lot of FIXNUM declarations in it, and it
ports just fine among all the stock-hardware machines we have around
here. We're not willing to do a lot of work now to figure out the
tightest possible integer range limits for each fixnum in order to make
things work on a hypothetical tiny-fixnum machine.
If people think that this is a matter of principle -- something either
is ABSOLUTELY PORTABLE or not -- then flonums have to go, along with
all character objects that are not standard-char-p, and a couple of
dozen other things. In my view, portability is a goal, not a
mathematical predicate.
Like Rob, I think that this debate has about run its course and should
be allowed to die a quiet death. Both sides are dug in, and the status
quo is going to win.
-- Scott
∂24-Jul-86 1547 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 24 Jul 86 12:38:58 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49159; Thu 24-Jul-86 15:37:45 EDT
Date: Thu, 24 Jul 86 15:39 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: (declare (type fixnum ---)) considered etc.
To: RAM@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12225040519.BABYL@C.CS.CMU.EDU>
Message-ID: <860724153907.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 23 Jul 1986 15:53 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Almost every other language in the entire world has a "INTEGER"
type which has an ill-defined, fixed precision. If Common Lisp is
going to have comparable performance to these languages when running
on the same hardware, then it is going to have to be comparably
inelegant.
Please demonstrate why ill-definition is crucial to good performance.
The fact that other languages are poorly-defined and non-portable do it
does not constitute a proof that it necesssary to be poorly-defined and
non-portable in order to perform well.
It's extremely easy for even a very dumb compiler to understand that a
program's declarations say that it needs at least 32 bits worth of
integer, and the hardware provides, say, 20 and 40, so it should use the
40-bit integers for the variable whose declaration says that it needs at
least 32.
∂24-Jul-86 1605 edsel!bhopal!jonl@navajo.stanford.edu (declare (type fixnum ---)) considered etc.
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 14:45:46 PDT
Received: by navajo.stanford.edu; Thu, 24 Jul 86 14:44:33 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA21387; Thu, 24 Jul 86 13:23:48 pdt
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA07304; Thu, 24 Jul 86 13:29:12 PDT
Date: Thu, 24 Jul 86 13:29:12 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8607242029.AA07304@bhopal.edsel.uucp>
To: navajo!DCP%QUABBIN.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!common-lisp%SU-AI.ARPA@navajo.stanford.edu
In-Reply-To: David C. Plummer's message of Thu, 24 Jul 86 13:34 EDT
Subject: (declare (type fixnum ---)) considered etc.
Re: If you really want to go least-common-denominator, you will probably
have to settle for 7 guarenteed bits, or maybe 8 or 9; I can't remember
how big MacLisp fixnums are.
MacLisp's fixnums are 36 bits in width; Interlisp-D's fixnums are 32 bits
wide (they are called FIXP's in Interlisp parlance).
There seems to be some confusion between the type FIXNUM with the (informal)
type "non-consing, small fixnum". Interlisp call's the latter variety
SMALLP's, and on the D machines they are 17 bits wide; MacLisp generally
guarantees non-consing behaviour only for a modest subrange of fixnums, but
the infamous NCOMPLR handles full 36-bit fixnums and generally avoids consing
them by using "strong typing" compiler techniques.
-- JonL --
∂24-Jul-86 1605 edsel!bhopal!jonl@navajo.stanford.edu Status of declare UNSPECIAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 14:46:05 PDT
Received: by navajo.stanford.edu; Thu, 24 Jul 86 14:44:53 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA21414; Thu, 24 Jul 86 13:31:27 pdt
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA07326; Thu, 24 Jul 86 13:36:47 PDT
Date: Thu, 24 Jul 86 13:36:47 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8607242036.AA07326@bhopal.edsel.uucp>
To: navajo!common-lisp%su-ai@navajo.stanford.edu
Subject: Status of declare UNSPECIAL
Was there ever a clear consensus one way or the other on this?
I remember it being brought up several times over the years, but
don't remember how it turned out.
In a previous note, I used the syntax (declare (notype x)). This
was a lapse into Maclisp style -- the common-lisp equivalent would
probably be (declare (type t x)).
-- JonL --
∂24-Jul-86 1740 FAHLMAN@C.CS.CMU.EDU Case of symbols and their print-names
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 17:32:21 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 24 Jul 86 20:32:09-EDT
Date: Thu, 24 Jul 1986 20:32 EDT
Message-ID: <FAHLMAN.12225353429.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: David Singer <DSinger@SRI-KL.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Case of symbols and their print-names
In-reply-to: Msg of 24 Jul 1986 13:05-EDT from David Singer <DSinger at SRI-KL>
The case-sensitivity/case-conversion wars were long and bloody, and
that particular battlefield is still radioactive. We might take one
last look at this sometime down the road, after lots of other issues
have been decided and we're all in a good mood, but PLEASE let's not
reopen this issue now.
-- Scott
∂24-Jul-86 1804 FAHLMAN@C.CS.CMU.EDU Status of declare UNSPECIAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 18:02:18 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 24 Jul 86 21:02:26-EDT
Date: Thu, 24 Jul 1986 21:02 EDT
Message-ID: <FAHLMAN.12225358938.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: Status of declare UNSPECIAL
In-reply-to: Msg of 24 Jul 1986 16:36-EDT from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
The introduction of an UNSPECIAL declaration is on my list of issues to
raise at some point. Jonathan Rees has asked for this several times
over the past few years and has asked why is isn't in the language
already. I don't remember, and nobody else seems to either.
Since this obviously interacts with the scope-of-declarations stuff,
let's consider this as part of the same discussion.
-- Scott
∂24-Jul-86 2011 FAHLMAN@C.CS.CMU.EDU Structure sharing in arguments
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 20:10:10 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 24 Jul 86 23:09:58-EDT
Date: Thu, 24 Jul 1986 23:09 EDT
Message-ID: <FAHLMAN.12225382154.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Structure sharing in arguments
In-reply-to: Msg of 23 Jul 1986 13:21-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
The question of whether &rest args can be destructively modified has
become muddled together with the related question of whether they can be
returned from a function or otherwise passed outward. The old Lisp
Machine trick of stack-consing these things loses in such situations.
Setting aside, for now, the question of destructive modificationof &rest
args, I would like to get a clarification on the stack-consing business.
DCP says:
[Yes, Symbolics uses stack-consed &rest lists, and they will screw you
every now and then. >>> My view of our current position <<< is that the
efficiency issues (e.g., not calling copy-list on every &rest arg) are
outweighed by the programmer resources needed to implement the copying
only when necessary.]
My understanding, from the last time we discussed this, was that
everyone agreed that this behavior was illegal in Common Lisp (the &rest
arg is supposed to be a LIST, and not some object that disappears on
you), and that the Symbolics position was that their system should
detect those situations where stack-consing is unsafe and copy those
rest-lists to the heap. I think I heard that this was already being
done, but maybe this is one of those "in release 27, not yet delivered"
kinds of things.
Do we agree that it is illegal for rest-arg lists to evaporate, or is
that another issue that we have to discuss?
-- Scott
∂24-Jul-86 2020 FAHLMAN@C.CS.CMU.EDU Structure sharing in arguments
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 20:20:07 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 24 Jul 86 23:18:45-EDT
Date: Thu, 24 Jul 1986 23:18 EDT
Message-ID: <FAHLMAN.12225383753.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Structure sharing in arguments
By the way, one thing I proposed a long time ago, and plan to re-propose
now, is a new &MORE construct that would allow functions to take
arbitrary numbers of arguments in the style of LEXPR, keeping them on
the stack until asked for and not consing them into a list. I don't
want to debate this now -- give me a chance to propose it properly first
-- but I thought I'd better mention this as a piece of context that
might keep people from getting too tense about the efficiency of &rest
args.
-- Scott
∂24-Jul-86 2036 FAHLMAN@C.CS.CMU.EDU Declaration before variable
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 20:34:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 24 Jul 86 23:34:44-EDT
Date: Thu, 24 Jul 1986 23:34 EDT
Message-ID: <FAHLMAN.12225386659.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: NGALL@BBNG.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Declaration before variable
In-reply-to: Msg of 23 Jul 1986 22:01-EDT from NGALL at G.BBN.COM
In response to the following suggestion by REM:
(DEFUN (STRING FOO) ((INTEGER X1 X2) (STRING S) (REAL Z))
...)
I.e. anywhere a simple name can appear to introduce a new binding
of a variable or name of function, a list of two elements can appear
to both introduce the name and tell its type, including SPECIAL etc.
Anywhere a sequence of names can appear, a list of more than two
elements can appear, where the first element is the type and the
remaining elements are names, thus ... (INTEGER X1 X2) ... has the
same effect as ... (INTEGER X1) (INTEGER X2) ...
This idea has some merit, but in my view it is too radical a change to
consider now. Keep this in mind for Common Lisp 2000.
-- Scott
∂24-Jul-86 2051 FAHLMAN@C.CS.CMU.EDU Some easy ones (?)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 20:51:11 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 24 Jul 86 23:51:20-EDT
Date: Thu, 24 Jul 1986 23:51 EDT
Message-ID: <FAHLMAN.12225389688.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Andy Freeman <ANDY@SUSHI.STANFORD.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Some easy ones (?)
In-reply-to: Msg of 24 Jul 1986 12:56-EDT from Andy Freeman <ANDY at Sushi.Stanford.EDU>
If let* doesn't allow duplicate names, then we'll end up writing
nested let* expressions (which is senseless, let* was invented to
avoid nested let expressions) or using setq more than necessary.
I can't imagine any reasonable piece of code that would use the same
name twice in a LET*. At least, I can't imagine any such code that
would not be much clearer if done some other way. So I don't think that
we'll end up writing nested LET* forms if we outlaw duplicate variable
names in a LET*. Unless oyu can supply a reasonable example, I think
we're better off not making an exception for this one case.
-- Scott
∂24-Jul-86 2131 DT50@A.CS.CMU.EDU duplicate names in LET*
Received: from A.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 21:31:21 PDT
Date: 25 Jul 86 00:30 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Subject: duplicate names in LET*
CC: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12225389688.BABYL@C.CS.CMU.EDU>
The rule in Common Lisp should be that you can't have duplicate names in
the same LEXICAL ENVIRONMENT. This rules out duplicate names in a lambda
list or a LET, and duplicate tags in a tagbody. But it should not rule
out duplicate names in a LET* because the variables in a LET* are bound in
different lexical environments. Writing
(let* ((v1 e1) (v2 e2) (v3 e3))
body)
should be semantically equivalent to
(let ((v1 e1))
(let ((v2 e2))
(let ((v3 e3))
body)))
It is NOT clear what to do when duplicate names appear in a lambda list or
tagbody; ignoring all but the first occurrence is a quick and dirty fix
that is not justified by the rules of lexical scoping. But in the LET
expression above it is perfectly clear what should happen when v1, v2, and
v3 are the same symbol. The equivalent LET* expression therefore has a
well-defined meaning. Outlawing duplicate names in LET* promotes too
shallow a notion of consistency: one based on syntax rather than semantics.
-- Dave
PS: We should also outlaw duplicate names in DO, but not DO*.
∂24-Jul-86 2236 franz!smh@kim.Berkeley.EDU (declare (type fixnum ---)) considered etc.
Received: from KIM.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 22:35:49 PDT
Received: by kim.Berkeley.EDU (5.53/1.14)
id AA26959; Thu, 24 Jul 86 22:36:06 PDT
Received: by franz (5.5/3.14)
id AA09731; Thu, 24 Jul 86 22:11:10 PDT
Date: Thu, 24 Jul 86 22:11:10 PDT
From: franz!smh@kim.Berkeley.EDU (Steve Haflich)
Message-Id: <8607250511.AA09731@franz>
To: common-lisp@su-ai.arpa
In-Reply-To: ucbkim!mit-ems.ARPA!NGALL%G.BBN.COM's message of 23 Jul 1986 23:18-EDT
Subject: (declare (type fixnum ---)) considered etc.
Date: 23 Jul 1986 23:18-EDT
From: NGALL%G.BBN.COM
My solution is to write (integer 0 #.array-dimension-limit).
It works just fine.
-- Nick
Of course this `works fine', but perhaps what better captures your
intended efficiency is an *exclusive* upper limit:
(integer 0 (#.array-dimension-limit))
But note that with such a declaration on the array index i, this
innocuous code could fail:
(let ((len (length my-array)))
(do ((i 0 (1+ i)))
((> i len))
...))
∂24-Jul-86 2248 NGALL@G.BBN.COM Re: duplicate names in LET*
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 22:47:51 PDT
Date: 25 Jul 1986 01:45-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: duplicate names in LET*
From: NGALL@G.BBN.COM
To: Dave.Touretzky@A.CS.CMU.EDU
Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]25-Jul-86 01:45:01.NGALL>
In-Reply-To: The message of 25 Jul 86 00:30 EDT from Dave.Touretzky@A.CS.CMU.EDU
Date: 25 Jul 86 00:30 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Subject: duplicate names in LET*
In-Reply-To: <FAHLMAN.12225389688.BABYL@C.CS.CMU.EDU>
The rule in Common Lisp should be that you can't have duplicate names in
the same LEXICAL ENVIRONMENT. This rules out duplicate names in a lambda
list or a LET, and duplicate tags in a tagbody. But it should not rule
out duplicate names in a LET* because the variables in a LET* are bound in
different lexical environments. ...
Wait a second. The optional and keyword parameters are NOT in the
same lexical environment, they are in nested ones, e.g.,
((lambda (&optional (v1 e1) (v2 e2) (v3 e3)) body))
is semantically equivalent to
(let* ((v1 e1) (v2 e2) (v3 e3))
body)
So why should lamda-lists be treated differently than LET*?
∂25-Jul-86 0519 vanroggen%bach.decnet@hudson.dec.com duplicate LET* variables
Received: from HUDSON.DEC.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 05:19:02 PDT
Date: 25 Jul 86 08:15:00 EST
From: "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>
Subject: duplicate LET* variables
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: vanroggen
Reply-To: "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>
Although I agree with Touretzky's reasoning about not having duplicate
names in the same lexical environment (I might as well add: except
when covered by the shadowing rules), I thought the problem with LET*
was the ambiguity regarding declarations, which is why LET* isn't the
same as a bunch of nested LETs.
---Walter
------
∂25-Jul-86 0654 Skef@Think.COM Re: REDUCE args
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 06:54:14 PDT
Received: from wenceslas by Godot.Think.COM via CHAOS; Fri, 25 Jul 86 09:54:29 edt
Date: Fri, 25 Jul 86 09:55 EDT
From: Skef Wholey <Skef@Think.COM>
Subject: Re: REDUCE args
To: DCP@QUABBIN.SCRC.Symbolics.COM, NGALL@G.BBN.COM,
ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860724145929.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-Id: <860725095514.1.SKEF@WENCESLAS.THINK.COM>
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
From: ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Subject: REDUCE args
Does anybody else wish that REDUCE took a KEY argument, similarly to MEMBER.
i.e.
(reduce #'+ list-of-objects :KEY #'object-quantity)
would apply the function OBJECT-QUANTITY to each element of the
list-of-objects before reducing it with +.
Ditto. I think GLS made some comment about this usage of :KEY being
different than most. Maybe that was in a different discussion. There
are possibly other related operations that should take KEY. One could
also add :TEST to avoid calling the operator on objects you don't want
to. Maybe this was Steele's point: Does the key apply before or after
the test? I think the intuitive usage is backwards from the other
usages.
It "being different than most" was my reaction, too. In all other
cases, the :KEY argument is used to specify a "field" to be used for
selection (via :TEST or :TEST-NOT). If :KEY were added to REDUCE in a
manner consistent with the rest of the language, it would only be useful
in conjunction with :TEST and :TEST-NOT, to either include or exclude
elements of the sequence from the reduction, which isn't what everyone
here seems to want. Read pages 245-256. Count one vote against, in the
name of maintaining the (somewhat pudding-like) consistency the language
has. In the meantime, you can of course do something like:
(reduce #'fun (map 'vector #'key sequence))
Now-living-on-a-3600-and-not-caring-too-much-about-consing-or-81-character-lines,
Skef
∂25-Jul-86 0754 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM FIXNUM considered useful
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Jul 86 07:54:32 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49855; Fri 25-Jul-86 10:53:57 EDT
Date: Fri, 25 Jul 86 10:55 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: FIXNUM considered useful
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12225321784.BABYL@C.CS.CMU.EDU>
Message-ID: <860725105530.8.DLW@CHICOPEE.SCRC.Symbolics.COM>
Scott, I feel that the only point is to recognize explicitly in the spec
and manual that using FIXNUM creates a real hazard that your program may
not be portable. You, personally, clearly understand what the issue is,
and I'm sure you know that even though within your own environment you
haven't run into problems, nevertheless different programs, or more
exotic implementations, might cause a program to not port correctly.
The only real point here is that everyone who reads the spec should
understand it, too. As long as it's clear what FIXNUM does mean and
does not mean, then people can make a well-informed choice about whether
to use it or not, and everything should be fine. But in a language spec
that is devoted to providing program portability, any language feature
that has known non-portable aspects to it should be clearly marked as such.
∂25-Jul-86 0809 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Status of declare UNSPECIAL
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Jul 86 08:09:11 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49880; Fri 25-Jul-86 11:07:57 EDT
Date: Fri, 25 Jul 86 11:09 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Status of declare UNSPECIAL
To: Fahlman@C.CS.CMU.EDU, Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12225358938.BABYL@C.CS.CMU.EDU>
Message-ID: <860725110937.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
For the record, I also remember that we decided explicitly not to have
an "UNSPECAL" (whatever you call it) declaration, and I also don't
remember why. Unfortunately, I remember this discussing occurring
during a physical meeting, but someone should poke into the old archives
and see if there was any good reasoning that we should all know about.
Otherwise, I agree that there should be such a declaration.
∂25-Jul-86 0839 FAHLMAN@C.CS.CMU.EDU FIXNUM considered useful
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 08:39:37 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 25 Jul 86 11:36:28-EDT
Date: Fri, 25 Jul 1986 11:36 EDT
Message-ID: <FAHLMAN.12225518046.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: FIXNUM considered useful
In-reply-to: Msg of 25 Jul 1986 10:55-EDT from Daniel L. Weinreb <DLW at QUABBIN.SCRC.Symbolics.COM>
Scott, I feel that the only point is to recognize explicitly in the spec
and manual that using FIXNUM creates a real hazard that your program may
not be portable...
As long as it's clear what FIXNUM does mean and
does not mean, then people can make a well-informed choice about whether
to use it or not, and everything should be fine. But in a language spec
that is devoted to providing program portability, any language feature
that has known non-portable aspects to it should be clearly marked as such.
I agree with this. It's what I've said about this all along. Too bad
the spec won't have red ink for such things, so nobody could claim they
missed it.
-- Scott
∂25-Jul-86 0843 DCP@QUABBIN.SCRC.Symbolics.COM Re: REDUCE args
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jul 86 08:40:40 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23972; Fri 25-Jul-86 11:39:04 EDT
Date: Fri, 25 Jul 86 11:39 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: REDUCE args
To: Skef Wholey <Skef@THINK.COM>, DCP@QUABBIN.SCRC.Symbolics.COM,
NGALL@G.BBN.COM, ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860725095514.1.SKEF@WENCESLAS.THINK.COM>
Message-ID: <860725113911.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Fri, 25 Jul 86 09:55 EDT
From: Skef Wholey <Skef@Think.COM>
In the meantime, you can of course do something like:
(reduce #'fun (map 'vector #'key sequence))
Now-living-on-a-3600-and-not-caring-too-much-about-consing-or-81-character-lines,
Somebody brought up this method the last time. I had at least two
reactions: (1) It doesn't really express the intent of the programmer,
and (2) I don't care what kind of machine you are on, you should care
about efficiency and consing.
∂25-Jul-86 0911 DCP@QUABBIN.SCRC.Symbolics.COM Re: Some easy ones (?)
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jul 86 09:02:03 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23986; Fri 25-Jul-86 12:01:05 EDT
Date: Fri, 25 Jul 86 12:01 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Some easy ones (?)
To: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA
cc: Fahlman@C.CS.CMU.EDU
In-Reply-To: <[G.BBN.COM]24-Jul-86 15:29:46.NGALL>
Message-ID: <860725120119.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 24 Jul 1986 15:29-EDT
From: NGALL@G.BBN.COM
Yes. PARSE-BODY called with DECLARATIONS-ALLOWED-P of NIL would be
used to verify that an implicit PROGN does not begin with decls (it
could be used with 'bodies' other than implicit PROGNs, but only if
such bodies do not allow a declaration-like syntax (unlike CASE and
COND (boy, did I pick a bad example!)).
Yes. Its contract would be to make sure there aren't any declarations.
This was the point I was trying (and failing so miserably) to make.
PARSE-BODY currently has no contract to make sure declarations are only at
the beginning. To do so it might have to expand macros (needlessly).
Therefore it isn't suitable for your intent of using it to verify
implicit PROGNs. Consider
(when (predicate)
(print 'foo)
(declare (inline xyzzy))
(print 'bar))
which is illegal. PARSE-BODY is for parsing bodies. Period. Implicit
PROGNs are not bodies. Really. PARSE-BODY's contract should be simple:
extract the three components of a body: the declarations, the
documentation, and the implicit PROGN. That is what a body is.
Something that isn't that isn't a body.
∂25-Jul-86 0922 Skef@Think.COM Re: REDUCE args
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 09:12:13 PDT
Received: from wenceslas by Godot.Think.COM via CHAOS; Fri, 25 Jul 86 12:12:21 edt
Date: Fri, 25 Jul 86 12:13 EDT
From: Skef Wholey <Skef@Think.COM>
Subject: Re: REDUCE args
To: DCP@QUABBIN.SCRC.Symbolics.COM, Skef@THINK.COM, NGALL@G.BBN.COM,
ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860725113911.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-Id: <860725121309.3.SKEF@WENCESLAS.THINK.COM>
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Fri, 25 Jul 86 09:55 EDT
From: Skef Wholey <Skef@Think.COM>
In the meantime, you can of course do something like:
(reduce #'fun (map 'vector #'key sequence))
Somebody brought up this method the last time. I had at least two
reactions: (1) It doesn't really express the intent of the programmer,
and (2) I don't care what kind of machine you are on, you should care
about efficiency and consing.
However, it is very easy to write a compiler transform that turns the
above into a call to a hidden function that does what the above does
without consing. The sequence functions are the most obvious, easiest
target for source-level optimization in a Common Lisp compiler. If the
above were listed as an idiom in the manual, then such optimizers might
appear in implementations. This is a real alternative, not some
pie-in-the-sky "a smart compiler could..." argument.
I feel the argument about consistent use of :KEY, :TEST, and :TEST-NOT
still holds. I don't object to adding a field selector argument to
REDUCE, but I don't think that it should be called :KEY. One might
introduce a new function, REDUCE-FIELD (or whatever), or a new keyword.
--Skef
∂25-Jul-86 1026 willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Proposal #13: Structure Sharing in Arguments
Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jul 86 10:17:47 PDT
Received: from tektronix by csnet-relay.csnet id ae23107; 25 Jul 86 12:57 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA09523; Wed, 23 Jul 86 13:00:56 PDT
Received: by tekchips.TEK (5.31/6.16)
id AA00325; Wed, 23 Jul 86 13:03:27 PDT
Message-Id: <8607232003.AA00325@tekchips.TEK>
To: common-lisp@SU-AI.ARPA
Cc: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Subject: Proposal #13: Structure Sharing in Arguments
Date: 23 Jul 86 13:03:26 PDT (Wed)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Similarly, a function that takes a &REST argument should not
destructively modify it because in some implementations its top-level
list structure might share with a list that the user gave as the last
argument to APPLY.
This clarification will imply that any accurate account of the semantics
of Common Lisp must explain the procedure call mechanism in terms of
linked lists. It will imply that people who care about portable code
must make a habit of copying every &REST argument themselves, despite
the fact that in any reasonable implementation the &REST argument will
have been freshly consed. It will force people who care about efficiency
to write non-portable code. This clarification is a very bad thing.
Does anyone claim that this clarification is a good thing?
Peace,
William Clinger
Tektronix Computer Research Laboratory
∂25-Jul-86 1127 shebs%utah-orion@utah-cs.arpa Re: Proposal #13: Structure Sharing in Arguments
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jul 86 11:26:55 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA05914; Fri, 25 Jul 86 12:27:08 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA05634; Fri, 25 Jul 86 12:27:04 MDT
Date: Fri, 25 Jul 86 12:27:04 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8607251827.AA05634@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: Proposal #13: Structure Sharing in Arguments
Summary:
Expires:
References: <8607232003.AA00325@tekchips.TEK>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <8607232003.AA00325@tekchips.TEK> willc%tekchips.tek.csnet@CSNET-RELAY.ARPA writes:
>
> Similarly, a function that takes a &REST argument should not
> destructively modify it because in some implementations its top-level
> list structure might share with a list that the user gave as the last
> argument to APPLY.
>
>This clarification will imply that any accurate account of the semantics
>of Common Lisp must explain the procedure call mechanism in terms of
>linked lists.
This doesn't make any sense. The clarification *simplifies* the
semantics of Common Lisp because it leaves undefined the situation
in which someone destructively modifies an &rest argument. "Bottom"
is simpler than anything else, eh?
> It will imply that people who care about portable code
>must make a habit of copying every &REST argument themselves, despite
>the fact that in any reasonable implementation the &REST argument will
>have been freshly consed. It will force people who care about efficiency
>to write non-portable code. This clarification is a very bad thing.
People who go about writing lots of destructive operations are best
off making copies of their data structures before starting to beat on them.
It's not perfect referential transparency, but it goes a long way to
getting predictable code.
"Reasonable implementation" is a pretty loaded term. If &rest args are all
freshly consed, then it compromises efficiency *all* the time, not just
the cases where someone decides that destructive operations are the thing
to do.
>Does anyone claim that this clarification is a good thing?
I do. (It is of course only a coincidence that PCLS *does* share arglist
pieces!) This clarification fits well with those parts of the standard
that don't promise whether DELETE and REMOVE have distinguishable behavior,
or how many bits are in a short float, etc.
stan
∂25-Jul-86 1157 @MC.LCS.MIT.EDU:uucp@CCC.MIT.EDU
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 11:57:31 PDT
Received: from CCC.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 JUL 86 15:00:12 EDT
Date: 25 Jul 1986 14:45:51-EDT
From: uucp@MIT-CCC
From gjc%LMI-ANGEL.ARPA Fri Jul 25 14:41:42 1986 remote from lmi-angel
Received: from LMI-LAMBDA-2-B by lmi-angel.ARPA (4.12/4.7) with CHAOS id AA02405; Fri, 25 Jul 86 14:38:56 edt
Date: Friday, 25 July 1986, 14:39-EDT
From: George Carrette <lmi-angel!gjc%LMI-ANGEL.ARPA>
Subject: FIXNUM considered unportable
To: mitccc!common-lisp%SU-AI%mc@angel.ARPA
Message-Id: <[LMI-LAMBDA-2-B].25-Jul-86 14:39:27.GJC>
What all this discussion says to me as a compiler implementor is that
I should give a warning when somebody uses type FIXNUM.
Ah, but show now I can think of a use of type FIXNUM from MACSYMA
(DOE-MACSYMA, CL-MACSYMA whatever), and it seems quite reasonable.
Given that we know that fixnum operations are more efficient than non-fixnum
we choose to do our math modulo various prime numbers that fit in a fixnum.
Macsyma has a list of the 10 or so bigest primes that fit in a fixnum for
each machine it runs on, and/or it can compute these on the fly, using the
(LSH -1 -1) idiom (or other more common-lisp ways of finding the greatest fixnum).
Well, thats part of the justification, the code would look something like:
(COND ((TYPEP *MODULUS* 'FIXNUM)
(LET ()
(DECLARE (FIXNUM *MODULUS*))
....frob... frob... frob...))
('ELSE
..... frob ... frob ...))
∂25-Jul-86 1214 gls@Think.COM Structure sharing in arguments
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 12:06:06 PDT
Received: from ignatius by Godot.Think.COM via CHAOS; Fri, 25 Jul 86 15:05:44 edt
Date: Fri, 25 Jul 86 15:06 EDT
From: Guy Steele <gls@Think.COM>
Subject: Structure sharing in arguments
To: miller@UR-ACORN.ARPA, DCP@QUABBIN.SCRC.Symbolics.COM
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <860723142439.9.MILLER@UR-CASHEW.ARPA>
Message-Id: <860725150616.3.GLS@IGNATIUS.THINK.COM>
Date: Wed, 23 Jul 86 14:24 EDT
From: Brad Miller <miller@UR-ACORN.ARPA>
Date: Wed, 23 Jul 86 13:21 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Tue, 22 Jul 86 21:39:37 pdt
From: hpfclp!diamant@hplabs.HP.COM
From: Scott Fahlman <fahlman@C.CS.CMU.EDU>
Subject: Some easy ones (?)
Proposal #13: Structure Sharing in Arguments
Clarification:
Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
Similarly, a function that takes a &REST argument should not
destructively modify it because in some implementations its top-level
list structure might share with a list that the user gave as the last
argument to APPLY.
I don't really care whether you add a restriction not to do destructive
operations on a &REST or &BODY argument, but it better be clear that the
list returned may not be something which will go away on exiting the function
(which could happen if the parameter list were stored on the stack and a
pointer to that list was returned -- apparently what Symbolics does).
Nothing currently in CLtL limits me from doing the following (nor should it):
(defun foo (&rest x) x)
...
[Yes, Symbolics uses stack-consed &rest lists, and they will screw you
every now and then. ...]
I'm fairly convinced that disallowing destructive operations on &rest
lists is funtionally equivalent to not being allowed to store them in
stable storage or to return them. ...
Now wait a second. (defun foo (&rest x) x) is not destroying the rest
argument. The problem is that the programmer who uses the result of foo
may destroy that result. Should he have to know how foo is implemented
to know what he is allowed to do to the result? I should think not....
I think the lesson here is that, in general, you shouldn't ever clobber
a CONS if you don't know where it has been. Certain CL primitives do
guarantee to cons up fresh lists, and you can safely clobber their
results. Everything else you ought to be careful with, and that
includes &rest arguments, the results of PARSE-BODY, the results of FOO,
and so on. Unless a function or other construct is clearly documented
to indicate that it is okay to clobber its result, then you should avoid
doing so.
--Guy
∂25-Jul-86 1233 REM@IMSSS Accidental clobbering of pnames etc.
Received: from IMSSS by SU-AI with PUP; 25-Jul-86 12:33 PDT
Date: 25 Jul 1986 1155-PDT
From: Rem@IMSSS
Subject: Accidental clobbering of pnames etc.
To: COMMON-LISP@SU-AI
As an alternative to current anarchy and my earlier proposal to have
extra runtime types for readonly-string etc., perhaps we could have a way
to declare things readonly. There are two kinds: (1) This function is
guaranteed not to modify this particular argument; (2) This returned value
must not be modified by anyone. The compiler can then be fixed so that
it's ok to pass (2) data as (1) args, but not as non-(1) args. User functions
can be declared not to ever modify their args, and the compiler can verify
this is indeed true when compiling those functions. Global variables can
be declared (3) this variable may contain data that should never be modified,
then it's permissible to store (2) data in that variable and impermissible
to destructively modify anything stored there. Any time data is picked
out of a readonly variable or a readonly returned value, that sub-data is
also considered to be readonly, and the compiler enforces that nobody
tries to modify it or put it where somebody else would be allowed to
modify. Of course when a total copy (including copying bytes of strings
etc.) of data occurs that resultant data is no longer considered readonly.
This is overkill in the sense that if you have one little piece of readonly
data which you insert into something else, that whole large object is
readonly, and if then a part is extracted from some place unrelated to
the truly readonly data that part is unnecessarily readonly, but the
programmer can avoid that by copying the little readonly piece in the
first place before sticking it into the big structure. Anyway, compiled
code will then never clobber PNAMEs etc. with this proposal implemented.
(Maybe even a super-smart interpretor could respect the declarations??)
-------
∂25-Jul-86 1454 gls@Think.COM Re: REDUCE args
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 14:50:40 PDT
Received: from ignatius by Godot.Think.COM via CHAOS; Fri, 25 Jul 86 17:50:32 edt
Date: Fri, 25 Jul 86 17:51 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: REDUCE args
To: DCP@QUABBIN.SCRC.Symbolics.COM, Skef@THINK.COM, NGALL@G.BBN.COM,
ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <860725113911.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-Id: <860725175113.5.GLS@IGNATIUS.THINK.COM>
Date: Fri, 25 Jul 86 11:39 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Fri, 25 Jul 86 09:55 EDT
From: Skef Wholey <Skef@Think.COM>
In the meantime, you can of course do something like:
(reduce #'fun (map 'vector #'key sequence))
Now-living-on-a-3600-and-not-caring-too-much-about-consing-or-81-character-lines,
Somebody brought up this method the last time. I had at least two
reactions: (1) It doesn't really express the intent of the programmer,
and (2) I don't care what kind of machine you are on, you should care
about efficiency and consing.
I buy your argument (2), but (1) seems to be a bit spurious.
Why isn't the intent "take all those keys and reduce them"?
If that is the intent, why can't that be expressed as
"(take all those keys) and (reduce them)"? Is it that
you had rather in mind "reduce all them thar keys"
and don't consider the other an equivalent formulation?
--Guy
∂25-Jul-86 1454 gls@Think.COM duplicate names in LET*
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 14:45:21 PDT
Received: from ignatius by Godot.Think.COM via CHAOS; Fri, 25 Jul 86 17:45:18 edt
Date: Fri, 25 Jul 86 17:45 EDT
From: Guy Steele <gls@Think.COM>
Subject: duplicate names in LET*
To: Dave.Touretzky@A.CS.CMU.EDU, Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <8607250432.AA09415@Zarathustra.Think.COM>
Message-Id: <860725174559.4.GLS@IGNATIUS.THINK.COM>
Date: 25 Jul 86 00:30 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
The rule in Common Lisp should be that you can't have duplicate names in
the same LEXICAL ENVIRONMENT. ...
Perhaps you meant "lexical contour"?
--Guy
∂25-Jul-86 1714 Masinter.pa@Xerox.COM Re: FIXNUM considered useful
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 17:06:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 25 JUL 86 15:57:23 PDT
Date: 25 Jul 86 12:51 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: FIXNUM considered useful
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Fri,
25 Jul 86 11:36 EDT
To: common-lisp@su-ai.ARPA
Message-ID: <860725-155723-1043@Xerox>
Its possible to be more explicit about the implementation dependent
range of fixnums without resorting to red ink.
In explicit terms of CLtL, I'd propose the following changes in wording:
On pp 14-15, move the paragraph "In every Common Lisp implementation
...."
to the end of the section on "Integer" (rather than the middle) and
put it in an Implementation Note rather than in the running text.
Change "In every Common Lisp implementation..." to "In most Common Lisp
implementations ..." and change "... is visible to the user in only a
few places where the efficiency of representation is important." to "...
is usually only visible to the user in cases where fixnum operations are
substantially more efficient than those that admit bignums." The
"efficiency of representation" is bogus: (signed-byte 8) is more
efficient in representation than fixnum. Fixnum declarations are not for
efficiency of representation but rather for efficiency of operations
such as + and *.
Add, after the sentence "Exactly which integers are fixnum is
implementation-dependent ..." a sentence: "For this reason, references
to the distinction between fixnum and bignum should be avoided in
portable code when more explicit integer ranges can be supplied." Add,
to the list of tokens to "See" the names "integer", "signed-byte".
∂25-Jul-86 2027 ANDY@Sushi.Stanford.EDU Re: Some easy ones (?)
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 20:27:09 PDT
Date: Fri 25 Jul 86 20:25:31-PDT
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: Re: Some easy ones (?)
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@Sail.Stanford.EDU
In-Reply-To: <FAHLMAN.12225389688.BABYL@C.CS.CMU.EDU>
Message-ID: <12225647140.10.ANDY@Sushi.Stanford.EDU>
Summary: The "no repeated names" rule removes a potential ambiguity
for let; let* doesn't have that ambiguity.. Since they are different,
exempting let* from the rule merely acknowledges their difference
rather than introducing an exception. Repeated variable names are
better than some obvious alternatives.
I'll get to &aux and &optional names at the end of this message.
Let* is different from let because it REQUIRES multiple lambda
expressions. Disallowing repeated names makes almost as much sense as
disallowing shadowing.
There is a reason to forbid repeated names in lambda-expressions (and
therefore let), do, labels, and the like. That reason is to avoid
ambiguity.
Let* (and possibly do*, I'm not sure about it) with repeated names is
NOT ambiguous. Pervasive declarations don't make it ambiguous; the
declaration affects the outermost instance of a name.
I use let* and repeated names when I am refining two or more objects
together. (I also use repeated names when I am successively refining
one object because it's easier to read than composing and allows me to
pass the unrefined object in multiple places to the refining function.)
It lets me use the same descriptive name everywhere for a given class
of object; scoping guarantees that I always have the right one. For
example:
(let* ((success (build-success code1 success failure))
(failure (build-failure code2 success failure))
(success (build-success code3 success failure)))
<body>)
None of the following are clearer. Are there clearer alternatives?
(let* ((code1-success (build-success code1 success failure))
(failure (build-failure code2 success failure))
(success (build-success code3 success failure)))
<body>)
(let* ((success (build-success code1 success failure))
(failure (build-failure code2 success failure)))
(let ((success (build-success code3 success failure)))
<body>))
(progn
(setq success (build-success code1 success failure))
(setq failure (build-failure code2 success failure))
(setq success (build-success code3 success failure))
<body>)
&optional variables fall in a grey area. If the caller passes enough
arguments, they are just like other variables. If not, they are sort
of like &aux variables. Consistency tips the balance, &optional
variables should be handled like non-optional names when it comes to
the no-repeated-names rule.
As to &aux, CLtL says it's a matter of style whether one uses it or
not. I chose not to so I don't care if repeated names are forbidden
even though they wouldn't be if the programmer used let*. (It would
be an exception to a useful rule, "all names in a lambda-expression
must be unique", to allow shadowing &aux variables. I'd rather flush
&aux though.)
-andy
-------
∂25-Jul-86 2034 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM (declare (type fixnum ---)) considered etc.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Jul 86 20:34:09 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 50007; Fri 25-Jul-86 12:26:24 EDT
Date: Fri, 25 Jul 86 12:28 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: (declare (type fixnum ---)) considered etc.
To: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12225287225.BABYL@C.CS.CMU.EDU>
Message-ID: <860725122802.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 24 Jul 1986 14:28 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
I don't think we should have people who never use type declarations
telling those of us who do what kind of declarations we can and can't
use. Nor do I think a company should change Common Lisp so that
everyone has to buy their machines to run fast.
I don't think we should make language design issues on the basis of ad
hominem attacks. A point is valid no matter who makes it. Common Lisp
language design is made by virtue of reason, not attacks. Furthermore,
nobody is proposing to change Common Lisp.
I'm getting tired of this discussion. Why doesn't everyone just admit
we aren't going to get agreement on this issue. The split seems to be
drawn largely along special-hardware/standard-hardware lines, and
neither community is going to go away.
This simply isn't true. If I were only using standard-hardware
machines, I would still be quite concerned that a program that declared
something to be a "fixnum" might suddenly not port to another
standard-hardware machine if it had a different word size.
In any case, flushing the
fixnum declaration is not one of the proposals we are supposed to be
discussing. If it were, it would be unlikely to pass, since under the
criteria for changes, approval would have to be near-unanimous, which
it isn't.
"Flushing the fixnum declaration"? To quote the mail that you are
attacking:
Date: Thu, 24 Jul 86 13:59 EDT
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: (declare (type fixnum ---)) considered etc.
To: RAM@C.CS.CMU.EDU, Cassels@STONY-BROOK.SCRC.Symbolics.COM
I didn't say we shouldn't have type FIXNUM. I said we should put it
somewhere where it would be obvious that programs using it are probably
not portable.
Don't you think you ought to read the message before flaming at the
sender? Let me make it clear again: Cassels is not advocating removing
the FIXNUM declaration. Nor am I. Got it?
Now, the point in Cassels's message that I don't agree with is the very
last paragraph, which might be the one that stimulated your reply:
Date: Thursday, 24 July 1986 13:59-EDT
From: Robert A. Cassels <Cassels at STONY-BROOK.SCRC.Symbolics.COM>
Re: (declare (type fixnum ---)) considered etc.
If you want the freedom to be sloppy, or you really
can't limit the range, you must either pay the price of reduced
performance or buy a machine which doesn't need declarations to get
performance. [I never use type declarations in my CL programs.]
The disagreement is with the last sentence, which, while true, is
deceptive because his CL programs are not trying to be both portable and
effective (i.e. fast on standard hardware). I think it was intended to
be a lighthearted comment, but wasn't taken that way.
(1) Omit numeric declarations altogether. Pro: It's very easy to do.
Pro: The program is portable. Con: The program could be slowed down if
not on special hardware.
(2) Use careful (INTEGER 0 X) declarations. Con: It takes work to
figure out what precision is really needed. Pro: The program is
portable. Pro: The program runs fast everywhere.
(3) Use FIXNUM declarations. Pro: It's pretty easy to do. Con: The
program is not necessarly portable. Pro: The programs runs fast
everywhere that it does run.
Common Lisp should and does allow all three. The point is to make it
clear, through proper phrasing in the specification and documentation,
that this is what is going on.
∂26-Jul-86 0759 FAHLMAN@C.CS.CMU.EDU Some easy ones (?)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 07:59:21 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Jul 86 10:59:37-EDT
Date: Sat, 26 Jul 1986 10:59 EDT
Message-ID: <FAHLMAN.12225773488.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Andy Freeman <ANDY@SUSHI.STANFORD.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Some easy ones (?)
In-reply-to: Msg of 25 Jul 1986 23:25-EDT from Andy Freeman <ANDY at Sushi.Stanford.EDU>
Summary: The "no repeated names" rule removes a potential ambiguity
for let; let* doesn't have that ambiguity.. Since they are different,
exempting let* from the rule merely acknowledges their difference
rather than introducing an exception. Repeated variable names are
better than some obvious alternatives.
OK, we agree that the main ambiguity that this clarification is trying
to address comes up only in the parallel-binding forms and not in the
sequential-binding forms. So it is possible to come up with rules that
would allow the same variable to be bound N times in a single LET* form
without ambiguity. Nobody is claiming that this is impossible.
I am suggesting that repeatedly binding the same variable within a
single binding form is an inherently confusing thing to do and that we
shouldn't introduce an exception into what otherwise could be a clean
and simple rule -- a variable is bound only once by any one binding
form -- in order to make this weird style possible. (It may be that you
find this less confusing than I do because you think of LET* as nested
LAMBDAS while I think of it as a funny kind of LET, but I don't think
I'm alone in this.)
One nasty issue we would have to face if we allowed LET* to bind the
same variable multiple times is what to do about declarations that
affect the multiply-bound variable. This is particularly nasty if we go
with the proposed scheme (any of them) that ties such declarations tot
he scope of the variable being bound. Now you've got two or more scopes
for variable FOO, and only one place to put the declaration. In this
case, I think that nested LET* forms would indeed be less confusing.
Your example of code that is best expressed with multiple rebindings in
a LET* is unconvincing to me. I don't understand exactly what you mean
by "successively refining" an object, and I find your code example quite
confusing not only are you referring to two different locally-bound
variables, both named SUCCESS, but you've got free references to SUCCESS
and FAILURE in there as well. I can sort this out, but in the presence
of a declaration or two, it might be pretty tough.
(let* ((success (build-success code1 success failure))
(failure (build-failure code2 success failure))
(success (build-success code3 success failure)))
<body>)
So, to answer your question, I do find the version with three SETQs much
easier to follow, and a version with three nested LET forms would be
better if it is really important to do this with rebinding and not with
SETQ.
So I still have not seen any code where multiple rebinding within a LET*
is the least confusing way to do something. I admit that this is a
matter of taste and that reasonable people may differ on this, but I
suspect your proposed example would be confusing to a substantial
fraction of Common Lisp programmers, which makes it bad style in
general.
I don't want to get into an argument about style -- at least not on this
mailing list. My point is simply that allowing multiple use of the same
variable in a single LET* does break what would otherwise be a simple
and uniform rule, it hairs up the declaration scoping rules, and there's
no good reason to allow this since in the rare case where you want to do
this there are alternatives that are at least as good and arguably
better.
-- Scott
∂26-Jul-86 0954 NGALL@G.BBN.COM Re: Some easy ones (?)
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 26 Jul 86 09:54:14 PDT
Date: 26 Jul 1986 12:50-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Some easy ones (?)
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: ANDY@SU-SUSHI.ARPA, common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]26-Jul-86 12:50:48.NGALL>
In-Reply-To: <FAHLMAN.12225773488.BABYL@C.CS.CMU.EDU>
Date: Sat, 26 Jul 1986 10:59 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Andy Freeman <ANDY@SUSHI.STANFORD.EDU>
Subject: Some easy ones (?)
In-Reply-To: Msg of 25 Jul 1986 23:25-EDT from Andy Freeman <ANDY at Sushi.Stanford.EDU>
Message-ID: <FAHLMAN.12225773488.BABYL@C.CS.CMU.EDU>
....
I don't want to get into an argument about style -- at least not on this
mailing list. My point is simply that allowing multiple use of the same
variable in a single LET* does break what would otherwise be a simple
and uniform rule, it hairs up the declaration scoping rules, and there's
no good reason to allow this since in the rare case where you want to do
this there are alternatives that are at least as good and arguably
better.
-- Scott
Hear, Hear!
-- Nick
∂26-Jul-86 1054 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #13: Structure Sharing in Arguments
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 26 Jul 86 10:54:08 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 50688; Sat 26-Jul-86 13:53:22 EDT
Date: Sat, 26 Jul 86 13:55 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #13: Structure Sharing in Arguments
To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8607232003.AA00325@tekchips.TEK>
Message-ID: <860726135509.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: 23 Jul 86 13:03:26 PDT (Wed)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
in any reasonable implementation the &REST argument will
have been freshly consed.
That's an extremely odd idea. The entire reason that we have &REST
arguments at all is to avoid the need for consing the list. Had we
intended for the list to be freshly consed, we would never have
implemented &REST at all; we'd have just let the caller cons up a list
and pass it as a regular argument.
∂26-Jul-86 1127 ANDY@Sushi.Stanford.EDU Re: Some easy ones (?)
Received: from SUSHI.STANFORD.EDU by SU-AI.ARPA with TCP; 26 Jul 86 11:27:33 PDT
Date: Sat 26 Jul 86 11:25:44-PDT
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: Re: Some easy ones (?)
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@Sail.Stanford.EDU
In-Reply-To: <FAHLMAN.12225773488.BABYL@C.CS.CMU.EDU>
Message-ID: <12225811022.11.ANDY@Sushi.Stanford.EDU>
There are currently several declaration proposals. The following two
forms are equivalent under all those with pervasive declarations.
(let ((a (make-a)))
<declaration for a>
(let ((a (refine-a a)))
<body>))
(let* ((a (make-a))
(a (refine-a a)))
<declaration for a>
<body>)
I believe that shadowing within let* is no more misunderstandable than
shadowing in general. Almost everyone uses the same name in separate
functions for objects of a given class. Does that confuse anyone?
Pervasive declarations are attractive because most of us use the same
convention locally. Repeated names in let* are merely one instance of
this.
CL has thus far avoided most prescriptive style issues. (I find it
strange that Fahlman prefers setq to let. :-)) I have no objection to
a note in the manual suggesting that some people think it's bad style
to repeat names in let*, much like it suggests that special variables
should be surrounded by *'s. If we are opening up prescriptive style,
I'm sure Falhman, Gall and I agree that the latter is a more important
issue. (If special variables have to be *starred*, special
declarations and all of the associated confusion goes away.)
-andy
-------
∂26-Jul-86 1257 FAHLMAN@C.CS.CMU.EDU Some easy ones (?)
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jul 86 12:55:50 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Jul 86 15:56:03-EDT
Date: Sat, 26 Jul 1986 15:55 EDT
Message-ID: <FAHLMAN.12225827449.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Andy Freeman <ANDY@SUSHI.STANFORD.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: Some easy ones (?)
In-reply-to: Msg of 26 Jul 1986 14:25-EDT from Andy Freeman <ANDY at Sushi.Stanford.EDU>
CL has thus far avoided most prescriptive style issues.
This is not a prescriptive style issue per se. It is a question of
whether we should add a complex epicycle to the language in order to
accommodate a style that some of us think is worthless at best and
confusing at worst. I don't think the language spec should go out of
its way to stop you from using a confusing style, but I don't think it
should bend over backwords to make this possible.
This has come down to a matter of taste. I think that you're asking for
an ugly exception in order to support a deeply bogus piece of
programming style; you think that this is not an exception, but
recognizes some "difference" between LET* and other forms such as LET
and LAMBDA, and you also think that this funny use of LET* is more
obvious than the equivalent form using SETQs or nested LET's.
OK, since it's a just a matter of design taste -- we both agree that it
will work either way -- I'll propose both alternatives and we'll see
what the technical committee decides. I think we've stated our
respective cases at sufficient length.
-- Scott
P.S. Just so nobody gets the wrong idea from your humorous comment: I
don't prefer SETQ to LET without regard to context. I do prefer SETQ to
LET when you are in fact successively "refining" a particular value.
There are times when you want to rebind, but if you're diddling around
with a value the way you seem to be, SETQ works just fine.
∂26-Jul-86 1308 RPG An Etiquette Request from your Mailing List Maintainer
To: common-lisp@SU-AI.ARPA
Having been away from the Bay Area for 1 week, I returned to 260 Common
Lisp messages. I found the topics and arguments intriguing, but I found
the mail itself maddening. The problem is that almost all of the messages
that were responses to others included the text of the messages to which
they were responding. That is, many messages looked like this:
<incredibly long header>
<incredibly long header>
<incredibly long header>
<incredibly long header>
<original comment>
<secondary comment>
<tertiary comment>
<The comment: ``I agree with the tertiary comment.''>
I would like to suggest that people who send comments to this
list spend some time thinking about how to best present their
comments in such a way that the duplication of messages is
minimized. I realize that sometimes the original messages must
be partially included.
Examples of message-senders who send well-presented messages are Weinreb
and Fahlman. Please try to imitate their message-sending style.
When you feel you must send parts of other messages, only send the
parts required and only enough of the header to identify the exact
message for people who wish to consult their own archives for the
original.
One aspect of message-response that I wish to pessimize is the
message-responder's effort. Taking the time to compose a well-presented
response gives you time to think about your response and whether it
is truly necessary to send. Your mail goes to many hundreds, if not
thousands, of people.
Thank you.
-rpg-
∂26-Jul-86 1344 FAHLMAN@C.CS.CMU.EDU Proposal #13: Structure Sharing in Arguments
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jul 86 13:34:23 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Jul 86 16:34:30-EDT
Date: Sat, 26 Jul 1986 16:34 EDT
Message-ID: <FAHLMAN.12225834449.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal #13: Structure Sharing in Arguments
In-reply-to: Msg of 26 Jul 1986 13:55-EDT from Daniel L. Weinreb <DLW at QUABBIN.SCRC.Symbolics.COM>
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
in any reasonable implementation the &REST argument will
have been freshly consed.
That's an extremely odd idea. The entire reason that we have &REST
arguments at all is to avoid the need for consing the list. Had we
intended for the list to be freshly consed, we would never have
implemented &REST at all; we'd have just let the caller cons up a list
and pass it as a regular argument.
THAT's an extremely odd idea, in my view. It seems to me that the
entire reason we have &REST args is to allow users to call functions
with arbitrary numbers of arguments, and we inherited the &REST syntax
from MUDDLE or somewhere. If the idea was to avoid consing up a list,
why in the world did we specify that &REST returns a list, instead of
defining some version of LEXPR that passes back the extra args one by
one upon request. (As I said earlier, I will be proposing soon that we
add something along those lines. The lack of a non-consing way of
handling arbitrary numbers of arguments is a big omission in the
language.)
If we ignore stack-consing, we see that in the overwhelming majority of
cases the &REST list will necessarily be freshly consed from distinct
arguments that were passed to the function. Only in the case of the
last arg to APPLY is there a pre-existing list around that could be
incorporated into the &rest structure, and I now believe that we should
just require this list to be copied so the the whole issue goes away.
It won't affect overall efficiency in any noticeable way.
-- Scott
∂26-Jul-86 1411 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #13: Structure Sharing in Arguments
Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 26 Jul 86 14:11:18 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 50754; Sat 26-Jul-86 17:10:46 EDT
Date: Sat, 26 Jul 86 17:12 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #13: Structure Sharing in Arguments
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12225834449.BABYL@C.CS.CMU.EDU>
Message-ID: <860726171228.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
OK, I was exaggerating or overstating to the point of misstating myself;
I apologize. The reason for the &rest feature, as defined, is so that
functions can take arbitrary numbers of arguments, without going through
the obscure locution of consing up a semantically unnecessary list, and
without various problems of the Maclisp "LEXPR" construct, and without
undue inefficiency.
However, I don't think it's acceptable to require that the list be
freshly consed. Your message disregards an important case. One of the
things that's very useful to do with &rest arguments is to "pass them on
down" to further functions, using apply. Having used &rest for a long
time, we've found this usage pattern to be extremely common. For
example, we have many functions that take several arguments, followed by
a FORMAT control string, followed by an arbitrary number of format
arguments. We have programs that do this passing-down to many levels of
depth. By requiring that the entire list be copied for every such call,
the cost of function calling is raised very considerably. Such an
extreme penalty will strongly encourage programmers either to stay away
from function calling in such circumstances, or go back to explicitly
consing up lists in order to prevent the cost of copying.
I hope this clarifies what I was trying to say.
∂26-Jul-86 1433 FAHLMAN@C.CS.CMU.EDU Proposal #13: Structure Sharing in Arguments
Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jul 86 14:32:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Jul 86 17:33:08-EDT
Date: Sat, 26 Jul 1986 17:33 EDT
Message-ID: <FAHLMAN.12225845128.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal #13: Structure Sharing in Arguments
In-reply-to: Msg of 26 Jul 1986 17:12-EDT from Daniel L. Weinreb <DLW at QUABBIN.SCRC.Symbolics.COM>
Well, OK, if calling APPLY on a rest-arg really is not as rare as I
thought because of applications like the one you describe, then maybe it
is important to allow implementations to skip the copying in this case.
We are then left with something like Guy's rule: In general, it is not
safe to do destructive operations on a list unless you know where it
came from and who else might be holding on to it. A list obtained as a
rest arg is just one of the cases you have to copy before mashing, and
when in doubt you have to copy. Something like this rule probably needs
to be stated explicitly anyway, since some people seem to assume that it
is OK to bash lists unless you can prove that it isn't OK.
-- Scott
∂26-Jul-86 1626 FAHLMAN@C.CS.CMU.EDU Mailing list etiquette
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 16:26:00 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Jul 86 19:26:18-EDT
Date: Sat, 26 Jul 1986 19:26 EDT
Message-ID: <FAHLMAN.12225865729.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Mailing list etiquette
I was about to send a message of my own on mailing list etiquette when
RPG's mail went by. I endorse everything he says (in that message!),
and would like to add a few things.
As you all have seen by now, the volume of mail on this list is
tremendous. A number of people, including some members of the technical
committee, are having trouble keeping up, and the task of catching up if
you're off the network for a couple of days is daunting. Important
issues are being buried by less important ones.
I intend to slow down the pace a bit. People are travelling in the
summer, and some have objected at the speed with which issues 1 - 4 went
by. It was probably a mistake to introduce 10 new issues at once; I
forgot that there are NO easy issues in language design. On the other
hand, we cannot slow things down too much. A glance at the issues file
reveals that we've got something like 100 small issues to decide as of
now, with more to come, plus several very large ones like the error and
object-oriented facilities. We have to keep moving at a fast pace or
this will take years. Also, as things are going now, if I were to slow
down the pace, others would slip more issues of their own into the gaps.
If we are to make progress at a reasonable rate and not burn out a lot
of people whose inputs we need, we are going to have to slow up the pace
somewhat and work hard to make the discussions more coherent. I'm
hoping that this can be accomplished by a certain amount of informal
pressure from the moderator (me). If not, we'll have to consider more
radical measures, such as moving a lot of these discussions to another
list with fewer people on it. Nobody likes that idea, so we'll avoid it
as long as possible.
Let me suggest some guidelines for this discussion. If you don't like
these guidelines, reply to me privately; the last thing we need right
now is a discussion on this mailing list about the rules for discussions
on this mailing list.
1. Only the moderator (that's me) gets to introduce NEW issues for
discussion. If you've got some issue or proposal that you think we
should discuss, send it to me. I'll either send it on to the mailing
list, queue it on the issues list for later discussion, try to talk you
out of this idea, or work with you to debug the idea. Anyone who sends
a random new proposal directly to Common Lisp will get flamed at by the
moderator. Anyone who starts discussing an out-of-order proposal will
be flamed at as well. If flaming doesn't work, we have other methods
for neutralizing repeat offenders.
2. I will from time to time remind people of what topics are currently
on the table. Each proposal will have a number; messages relating to a
specific proposal should include that proposal's number in the header.
(I haven't been doing this consistently myself, but I will start.)
Issues that have not yet matured into proposals will be given some other
unique identifier such as "Scope of special declarations".
3. From time to time I will try to close off discussions that have
reached the point of diminishing returns. Sometimes this will take the
form of sending the issues on to the technical committee. Sometimes I
will declare that a proposal seems to be going nowhere and should be
dropped. In the latter case, the proposer may demand that the full
technical committee rule on his decision, since I alone am not able to
make binding technical decisions. In such cases, the issue will be sent
to the technical committee, along with my comments, for appropriate
action. (As a one time exception, since some people were taken by
surprise, comments on issues 1 - 4 are still allowed up until the time
when the technical committee's decision is announced.)
4. It is legitimate to endorse proposals, argue against them, or propose
amendments. If you're not sure whether an amendment is worth proposing
(for example, if you are not sure whether it is "too radical a change to
consider" I encourage you to send it to me or to some other person whose
judgement you respect to get a second opinion before you send this on to
the whole list. At the least, this will help to insure that amendments
are not obviously absurd or ill-formed; we all have blind spots. As
moderator, I reserve the right to rule certain amendments out of order
if I think that they are really totally new topics in disguise or if I
think that they will distract people from more important discussions
that are going on. We'll come back to such amendments later, unless the
proposer agrees to withdraw them.
5. PLEASE try to keep your messages short and to the point. As RPG
suggested, include only those parts of earlier messsages that are
necessary to establish context. When replying to another message, the
person you are addressing should be in the TO field and Common Lisp in
the CC field; don't let a lot of other names accumulate in the CC's.
If a you've fallen behind in your mail reading, read through all the new
messages FIRST, then go back and respond if you must. The most
irritating kind of message to get is one that jumps into the middle of
an old argument after the protagonists have reached a reasonable
conclusion (or the moderator has ruled the discussion out of order).
6. Always take the time to compose the clearest message you can, and
when you're done ask yourself once again whether sending the message is
really useful. Becoming the #1 message generator will make you famous
in the lisp community, but it may not be the kind of fame you want. As
moderator, I sometimes will need to respond quickly to keep the debate
from wandering off in useless directions; the rest of you don't have
that excuse. Don't put too much into any one message, and don't try to
toss out more than one really clever idea per week; NOBODY has more than
one clever idea per week.
If we all try to follow these guidelines, we may be able to finish this
job in finite time. It remains to be seen whether a task of this
complexity can be done by a group of this size, but it certainly cannot
be done if things go on as they have been.
Your servant (for as long as I can stand the pace),
Scott
∂26-Jul-86 1626 shebs%utah-orion@utah-cs.arpa Re: Proposal #13: Structure Sharing in Arguments
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 26 Jul 86 16:26:27 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA19126; Sat, 26 Jul 86 17:26:37 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA01397; Sat, 26 Jul 86 17:26:34 MDT
Date: Sat, 26 Jul 86 17:26:34 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8607262326.AA01397@utah-orion.ARPA>
Newsgroups: fa.common-lisp
Subject: Re: Proposal #13: Structure Sharing in Arguments
Summary:
Expires:
References: <FAHLMAN.12225845128.BABYL@C.CS.CMU.EDU>
Sender:
Reply-To: shebs@utah-orion.UUCP (Stanley Shebs)
Followup-To:
Distribution:
Organization: University of Utah CS Dept
Keywords:
Apparently-To: common-lisp@su-ai.arpa
In article <FAHLMAN.12225845128.BABYL@C.CS.CMU.EDU> Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) writes:
>We are then left with something like Guy's rule: In general, it is not
>safe to do destructive operations on a list unless you know where it
>came from and who else might be holding on to it.
We teach our students this already, although most textbooks seem to have
only a token warning against it. Perhaps the new standard should print
this in red with purple polka-dots?
stan
∂26-Jul-86 1824 masinter.PA@Xerox.COM Re: Some easy ones (?)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Jul 86 18:24:48 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 26 JUL 86 18:23:47 PDT
From: masinter.PA@Xerox.COM
Date: 26 Jul 86 18:22:55 PDT
Subject: Re: Some easy ones (?)
In-reply-to: FAHLMAN@C.CS.CMU.EDU's message of Sat, 26 Jul 86 15:55 EDT,
<FAHLMAN.12225827449.BABYL@C.CS.CMU.EDU>
To: FAHLMAN@C.CS.CMU.EDU
cc: Andy Freeman <ANDY@SUSHI.STANFORD.EDU>, common-lisp@SU-AI.ARPA
Message-ID: <860726-182347-1898@Xerox>
if you want simplicity, allowing duplicate names and just saying that
the last one shadows all the rest, both for references & for
declarations, would be the simplest rule.
(defun foo (a a )
(declare (special a))
...)
then the second a would get the special binding.
(defun foo () (let((a 1)(a 2))
a))
would return 2, etc.
Its a very simple rule. Its probably an easier rule to understand than
"its illegal, but lots of interpreters & compilers don't check for
illegality".
Its not hard to implement in the interpreter or the compiler, you just
have to be careful about what order you do things in.
There's lots of things you can do in Common Lisp that are bad style.
There's no reason to omit language features just because they're bad
programming style... the compiler isn't a style-checker.
∂26-Jul-86 1855 FAHLMAN@C.CS.CMU.EDU Some easy ones (?)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 18:55:17 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Jul 86 21:49:33-EDT
Date: Sat, 26 Jul 1986 21:49 EDT
Message-ID: <FAHLMAN.12225891798.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: masinter.PA@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Subject: Some easy ones (?)
In-reply-to: Msg of 26 Jul 1986 21:22-EDT from masinter.PA at Xerox.COM
if you want simplicity, allowing duplicate names and just saying that
the last one shadows all the rest, both for references & for
declarations, would be the simplest rule.
By no conceivable stretch of the imagination (mine, anyway) is this rule
simpler than saying "it is an error". I can't even figure out what you
mean by "the last one shadows all the rest for declarations", though I
could probably guess. As I said earlier, we've got a matter of design
taste here and further discussion is probably not going to change any
minds.
-- Scott
∂26-Jul-86 1913 ALAN@AI.AI.MIT.EDU Some easy ones (?)
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 19:13:29 PDT
Date: Sat, 26 Jul 86 22:23:50 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Some easy ones (?)
To: common-lisp@SU-AI.ARPA, masinter.PA@XEROX.COM
In-reply-to: Msg of 26 Jul 86 18:22:55 PDT from masinter.PA at Xerox.COM
Message-ID: <[AI.AI.MIT.EDU].76153.860726.ALAN>
Date: 26 Jul 86 18:22:55 PDT
From: masinter.PA at Xerox
if you want simplicity, allowing duplicate names and just saying that
the last one shadows all the rest, ...
(defun foo () (let((a 1)(a 2))
a))
would return 2, etc....
I was going to suggest exactly this. The only thing I would add is that in
cases like the above, a good compiler should issue a warning about the
variable named "A" that was bound but never referenced. Thus most (not
all) cases where a duplicated variable was the result of programmer error
will be brought to the programmer's attention. Other cases, such as the
LET* examples recently exhibited, will not provoke this warning from the
compiler.
∂26-Jul-86 2202 SAFIER%cgi.csnet@CSNET-RELAY.ARPA RE: Proposal 13
Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 26 Jul 86 22:02:16 PDT
Received: from cgi by csnet-relay.csnet id aa11866; 27 Jul 86 1:04 EDT
Date: Sat, 26 Jul 86 18:38 ???
From: SCOTT <SAFIER%cgi.csnet@CSNET-RELAY.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: RE: Proposal 13
I beleive that proposal 13 is a good one. A user of common lisp should
be warned that an implemenation of &rest might share structure with
some other list, or that &rest arguments may not be "freshly consed".
However, some implementations of common lisp which cons &rest arguments
from the stack have also imposed a limit on the number of values which
&rest can take. The upper limit for the particular implementation in
question seems to be 212 values. If any more than 212 values are passed
as an &rest argument, some internal stack overflows.
This implementation restriction makes it extremely difficult to write
portable code (and possibly impossible to code the particular task
that we are currently working on).
Although common lisp implementations should be allowed to cons &rest
arguments from the stack, they should not be allowed to impose a limit
on the number of values which can be passed to an &rest.
-Scott Safier
Carnegie Group Inc
(SAFIER@CGI.CSNET)
∂26-Jul-86 2227 FAHLMAN@C.CS.CMU.EDU Proposal 13
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 22:26:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 01:26:29-EDT
Date: Sun, 27 Jul 1986 01:26 EDT
Message-ID: <FAHLMAN.12225931299.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: SCOTT <SAFIER%cgi.csnet@CSNET-RELAY.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal 13
In-reply-to: Msg of Sat 26 Jul 86 18:38 ??? from SCOTT <SAFIER%cgi.csnet at CSNET-RELAY.ARPA>
This is your moderator speaking:
Scott Safier collects the first flame under the new dictatorial policy.
We'll make it a gentle one this time.
The business about limits on &rest args is a new issue disguised as
discussion of issue 13. PLEASE DO NOT RESPOND TO THIS. if he wants to
discuss this new issue, I have descirbe the proper procedure for
introducing it.
(No, I didn't put him up to this, but I should have.)
∂26-Jul-86 2253 FAHLMAN@C.CS.CMU.EDU Rules clarification
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 22:53:17 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 01:53:35-EDT
Date: Sun, 27 Jul 1986 01:53 EDT
Message-ID: <FAHLMAN.12225936232.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Rules clarification
In-reply-to: Msg of Sat 26 Jul 86 18:38 ??? from SCOTT <SAFIER%cgi.csnet at CSNET-RELAY.ARPA>
This is your moderator again:
[ Messages from me in the role of moderator will carry some version of
the above label. Otherwise, just assume that it is Scott Fahlman, one
of the many random participants in various design debates. I will try
to keep these roles separate, though it won't always be easy. ]
This mailing list is not ONLY for proposals and formal debate. We also
need a technical communication channel for use by the Common Lisp
community, and at present we have only the one mailing list. We may
need to fix that -- let's see how this goes.
Queries about what is currently legal, in the opinion of the rest of us,
are allowed. So are queries about how people have implemented various
things. If these queries result in debates or proposed clarifications,
then at some point we must invoke the formal mechanism that regulates
such things, or we'll be swamped all over again.
In the case of Safier's message, it was already a proposal, not a query,
and was on an issue likely to result in some debate. That's why he
should not have introduced it directly onto the list in the middle of
other discussions, instead of going through the moderator.
∂27-Jul-86 0936 FAHLMAN@C.CS.CMU.EDU Summary of current issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 09:36:19 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 12:36:38-EDT
Date: Sun, 27 Jul 1986 12:36 EDT
Message-ID: <FAHLMAN.12226053292.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Summary of current issues
This is your moderator:
The following issues are currently under discussion:
Proposals 1 - 4 if anyone feels that they were deprived of a chance to
comment on these because of the speed with which they went by. The
proposals have been sent to the technical committee, but voting will
probably not be completed before the Lisp conference.
Proposals 5 - 14. I will send out a message on each of these later
today, summarizing as best I can where the debate stands on each of
them.
The proposed changes to the scoping rules for Special and other
declarations. I will try to formulate the various suggestions into a
couple of specific alternative proposals we can shoot at.
The proposal to eliminate the FIXNUM data type or to hide it in the
SYSTEM package. I believe that the proponents of this change are now
willing to accept a clearer warning in the new specification about the
portability issues raised by the use of the FIXNUM declaration. Unless
someone requests an official decision from the technical committee on
this, I propose to drop this issue and retain the status quo (with the
stronger warning).
The proposal to add something like GC and BYE functions to the language.
Many variations on this theme have been proposed. However, I believe
that there is a substantial body of opposition to the whole idea, on the
grounds that it is very hard to come up with any sort of definition for
these things that makes sense across all implementations, and that these
things are therfore handled better as system-specific environment
extensions, outside the standard. We have many more essential issues to
discuss now, so I propose to put these issues back on the queue as part
of an item on what environment interface functions we want to have in
the standard, if any.
If there are other things that were touched on in recent debate and that
you want to add to the discussion queue, contact me directly. Please do
not send new issues to the mailing list directly.
-- Scott
∂27-Jul-86 1156 RPG Possible New Issues
∂26-Jul-86 2146 FAHLMAN@C.CS.CMU.EDU Possible New Issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 21:46:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 00:46:44-EDT
Date: Sun, 27 Jul 1986 00:46 EDT
Message-ID: <FAHLMAN.12225924058.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: fahlman@C.CS.CMU.EDU
Subject: Possible New Issues
In-reply-to: Msg of 26 Jul 1986 23:19-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
Dick,
The change to MV-BIND is something I opposed five years ago
(successfully), and still am not crazy about, though my attitude is no
longer "over my dead body". Presumably we require &allow-other-keys, et
al? &rest conses the extra values -- everyone would have to do some
clever optimizing in order to avoid consing values that they plan to
throw away (since we don't have &REST IGNORE).
If are sure you want to propose this, I'll put it on the list and
introduce it when a new fight seems tolerable. I think you'll see a
rather heated discussion between the people who say "of course the
language is more elegant this way" and the people who actually are faced
with implementing this. I'm probably less opposed to this than before
because it would be Rob's problem, not mine.
By way of classification, I would say that this would break some user
code that now depends on excess values beign dropped and unsupplied
values turning to NIL. I guess one could fix this mechanically by
turning all MV-BIND lists (x y z) into (&optional x y z &rest ignore).
Is that right? Should we propose special semantics for variables named
IGNORE at the same time? A lot of people seem to want this.
My reaction to the special proposal is that this is many steps over the
border for Common Lisp 87 (or whatever). It breaks lots of code in ugly
ways that could only be fixed by a person or a rather smart code-walker.
If I thought that such radical changes were in order, I would go one
step farther: a special ref to X would not be made by saying "X", but
only by saying (DYNAMIC X), for which we define a read macro such as $X.
Any binding form can bind a special value, but again the variable is
indicated as (DYNAMIC X) or $X rather than just X, right there on the
spot. The anomalous SPECIAL declaration woudl go away altogether.
The next time I do a language for my own enjoyment, this is how it's
going to work, but I think it's too late for Common Lisp.
Do you REALLY want to pursue this now?
-- Scott
∂27-Jul-86 1307 RPG Possible New Issues
∂27-Jul-86 1259 FAHLMAN@C.CS.CMU.EDU Possible New Issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 12:59:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 15:59:31-EDT
Date: Sun, 27 Jul 1986 15:59 EDT
Message-ID: <FAHLMAN.12226090225.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Possible New Issues
In-reply-to: Msg of 27 Jul 1986 15:06-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
OK, I'll keep the question about radical changes to SPECIAL in mind, and
will bring the question up if it looks to me like the overloading has
become unmanageable or if others start suggesting this.
Right now, I think I can predict what a poll would show: lots of people
who think that language design is an amusing abstract exercise would
favor radical changes, while those who have big piles of code to deal
with would take a very conservative line on a change of this size. As
you say, object-stuff might change that, once we get into it.
I find it pretty depressing that we can't even agree on things like
outlawing (LET* (FOO FOO FOO)...), but then it always was the dumb
little things that hung us up.
-- Scott
∂27-Jul-86 1523 FAHLMAN@C.CS.CMU.EDU Proposal #5 status
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 15:23:43 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 18:24:02-EDT
Date: Sun, 27 Jul 1986 18:23 EDT
Message-ID: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposal #5 status
Here is the first of the status reports on pending proposals. This is
culled from a lot of old mail; my apologies in advance if I missed some
key suggestion. I suggest that we use this as the starting point for
further discussion of this issue (and similarly with the others) and
that we try to converge on a final set of proposals for the technical
committee fairly soon. All of these summaries are from me as moderator;
where I have seen fit in inject one of my personal opinions on some
technical matter, that is marked.
-- Scott
---------------------------------------------------------------------------
There seems to be no opposition to the idea of PARSE-BODY per se. There
have been numerous suggestions about the exact form of the arguments and
return values, and I have incorporated most of these suggestions into
revised proposal 5A below: making the environment and doc-p arguments
optional, reordering the returns into what some consider a more natural
order, and returning the declarations as a combined list of
decl-specs (as the book calls them), without the surrounding DECLAREs.
One suggestion by Nick Gall is to add a declaration-allowed-p form. If
this is NIL, then PARSE-BODY has the task of ensuring that the body does
NOT contain declarations. Some people have responded that this
functionality does not belong in PARSE-BODY. (Speaking as SEF, I agree
with this view. Nick is free to pursue this further if he wants to,
but I suspect that the idea is not going anywhere.)
One complex issue is whether the body should be returned in its original
form or with any macro-expansion that was computed while looking for
initial decls replacing the original body forms. (There will only be
one of these, since the first non-declaration stops the expansion.) One
would like to avoid doing the work of expansion a second time, but
sometimes it is necessary to get at the original body. In 5A below, I
propose a solution that may get get the best of both worlds: the body is
returned in original form, but there are two additional return values,
one indicating the availability of a macro-expansion for the first body
form, and the other being that expansion. (Two extra values are
necessary because the macro might perversely expand into NIL after doing
a lot of work.)
---------------------------------------------------------------------------
Proposal #5A: PARSE-BODY
Extension:
Add a new function:
(PARSE-BODY body &optional environment documentation-allowed-p)
The default for environment is NIL, meaning to use a null lexical
environment. The default for documentation-allowed-p is NIL, meaning
that this form is NOT allowed to have a documentation string.
PARSE-BODY extracts the documentation string and declarations from BODY,
expanding initial macros as necessary to determine if they contain
declarations. It returns five values:
1. A documentation string (or NIL if none is present).
2. A combined list of declaration specs, extracted from all
DECLARE forms found at the start of the body, whether present in the
body itself or obtained via macro-expansion.
3. The remainder of the BODY argument, following any initial
doc-strings, declarations, or forms that expand into declarations.
4. The macro-expansion for the first form in return value 3, if any.
5. T if return 4 is a valid macro-expansion for the first form
in return 3, NIL otherwise.
∂27-Jul-86 1554 lmi-angel!rpk@EDDIE.MIT.EDU TYPE-SPECIFIER-P
Received: from MIT-EDDIE.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jul 86 15:53:39 PDT
Received: by EDDIE (5.31/4.7) id AA07726; Sun, 27 Jul 86 18:36:40 EDT
Received: by lmi-angel.ARPA (4.12/4.7) id AA21099; Sun, 27 Jul 86 18:37:02 edt
Date: Sun, 27 Jul 86 18:37:02 edt
From: Bob Krajewski <lmi-angel!rpk@EDDIE.MIT.EDU>
Message-Id: <8607272237.AA21099@lmi-angel.ARPA>
To: common-lisp@sail.stanford.edu
Subject: TYPE-SPECIFIER-P
I'm not sure if there really needs to a new type specifier (TYPE-SPECIFIER),
to go along with this. The Common Lisp type system should be used for the
discrimination of Lisp objects, whereas type specifiers are a kind of
``application'' of Lisp objects for a special purpose (the representation of
types). TYPE-SPECIFIER doesn't have the same kind of intrinsic quality that
STRING or VECTOR does.
∂27-Jul-86 1637 FAHLMAN@C.CS.CMU.EDU TYPE-SPECIFIER-P
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 16:36:33 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 19:36:28-EDT
Date: Sun, 27 Jul 1986 19:36 EDT
Message-ID: <FAHLMAN.12226129722.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Bob Krajewski <lmi-angel!rpk@MIT-EDDIE.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: TYPE-SPECIFIER-P
In-reply-to: Msg of 27 Jul 1986 18:37-EDT from Bob Krajewski <lmi-angel!rpk at EDDIE.MIT.EDU>
I agree with you. TYPE-SPECIFIER doesn't seem like a type to me, but
rather like some sort of meta-thing. I would find it a bit confusing to
include it among the types, though this is not one of the issues I can
get very passionate about.
-- Scott
∂27-Jul-86 1807 lmi-angel!rpk@EDDIE.MIT.EDU PARSE-BODY
Received: from MIT-EDDIE.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:07:20 PDT
Received: by EDDIE (5.31/4.7) id AA07721; Sun, 27 Jul 86 18:36:34 EDT
Received: by lmi-angel.ARPA (4.12/4.7) id AA21083; Sun, 27 Jul 86 18:35:58 edt
Date: Sun, 27 Jul 86 18:35:58 edt
From: Bob Krajewski <lmi-angel!rpk@EDDIE.MIT.EDU>
Message-Id: <8607272235.AA21083@lmi-angel.ARPA>
To: common-lisp@sail.stanford.edu
Subject: PARSE-BODY
Perhaps the argument list of PARSE-BODY should be
(BODY DOCUMENTATION-ALLOWED-P &OPTIONAL ENVIRONMENT)
to correspond with MACROEXPAND and friends (ENVIRONMENT being optional).
The most reasonable order of values would seem to be body, declarations (as
an alist, as MLY suggested), and the documentation string (that should go
last since forms do not always allow it. I'm still confused about the
macroexpansion to find documentation strings and declarations: did the spec
for Common Lisp ever have a say on this issue ?
∂27-Jul-86 1807 FAHLMAN@C.CS.CMU.EDU Proposal #6 Status: Parsing in &BODY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:01:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 21:01:31-EDT
Date: Sun, 27 Jul 1986 21:01 EDT
Message-ID: <FAHLMAN.12226145207.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposal #6 Status: Parsing in &BODY
Nobody seems to oppose this. One or two people have questioned its
usefulness, but the discussion we had on this a year or so ago
demonstrated considerable demand for this as an alternative to making
users handle environment objects directly.
Most people who commented on this prefer KMP's proposed syntax, though
there seems to be little enthusiasm for the inclusion of default and
supplied-p values. (Speaking for myself, I'm happy to go along with
this if we don't get into default/supplied-p complexities.) So, we have
a revised proposal:
---------------------------------------------------------------------------
Proposal #6A: Parsing in &BODY
Extension:
Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
(DEFMACRO name (... &BODY body-var [declarations-var [doc-string-var]]) ...)
If DECLARATIONS-VAR is present, it means to give the original body to
PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is
present) and then bind the variables to the corresponding values
returned by PARSE-BODY. This is purely a syntactic convenience for the
user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then
call PARSE-BODY himself.
Note: This extension is proposed only for &BODY, not for &REST, so &BODY
will no longer be exactly equivalent to &REST in a DEFMACRO arglist.
∂27-Jul-86 1810 ALAN@AI.AI.MIT.EDU Ordering suggestion
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:10:35 PDT
Date: Sun, 27 Jul 86 21:21:05 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Ordering suggestion
To: Common-Lisp@SU-AI.ARPA
Message-ID: <[AI.AI.MIT.EDU].76316.860727.ALAN>
I suggest that the PARSE-BODY and &BODY extension issues really should be
delayed until after the declaration scoping issue has been resolved. Given
that under most declaration proposals it is difficult to write a macro that
correctly redistributes the declarations found in a macro call to the
proper places in the expansion, it might be reasonable to use PARSE-BODY to
further classify declarations somehow.
Please note that I am not proposing to do this (yet), I'm not even certain
I think this is a good idea. Debate on the merits of the suggestion are
probably out of line. I'm just suggesting that we finish the declaration
issue before any more work on PARSE-BODY/&BODY.
∂27-Jul-86 1838 FAHLMAN@C.CS.CMU.EDU PARSE-BODY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:38:18 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 21:27:41-EDT
Date: Sun, 27 Jul 1986 21:27 EDT
Message-ID: <FAHLMAN.12226149970.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Bob Krajewski <lmi-angel!rpk@MIT-EDDIE.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: PARSE-BODY
In-reply-to: Msg of 27 Jul 1986 18:35-EDT from Bob Krajewski <lmi-angel!rpk at EDDIE.MIT.EDU>
...I'm still confused about the
macroexpansion to find documentation strings and declarations: did the spec
for Common Lisp ever have a say on this issue ?
Yes, see pages 153 and 154. It was discovered some time later that
this, coupled with the existence of macro-let, requires body-parsing
macros to get hold of the appropriate lexical environment (at least the
part of it that defines local macros) in order to correctly do this
expansion.
-- Scott
∂27-Jul-86 1845 FAHLMAN@C.CS.CMU.EDU Proposal #7 Status: TYPE-SPECIFIER-P
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:44:23 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 21:44:43-EDT
Date: Sun, 27 Jul 1986 21:44 EDT
Message-ID: <FAHLMAN.12226153071.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposal #7 Status: TYPE-SPECIFIER-P
Several people have proposed that this be restricted to take only
symbols, since that is the most important use, and it becomes hard to
specify exactly what things must be checked for correctness in the
myriad of more complex cases. (Speaking for myself, I favor this
change.) This is proposed in 7A below.
If someone wants to argue in favor of handling the more complex
type-specifiers as well, I would ask you to provide a specific and
detailed proposal for exactly what things must be examined in each case.
It was also suggested that we do this by (TYPEP arg 'TYPE-SPECIFIER), but
some opposition to this idea has also been expressed, on the grounds
that TYPE-SPECIFIER is not really a type in the usual sense. Also, if
we did this, it would be awkward to restrict the argument to being a
symbol.
---------------------------------------------------------------------------
Proposl #7A: TYPE-SPECIFIER-P
Proposed extension:
Add a new function (TYPE-SPECIFIER-P arg), where ARG must be a symbol.
If ARG is a valid type specifier, this returns T; else it returns NIL.
Note that the use of DEFSTRUCT and DEFTYPE can change the behavior of
TYPE-SPECIFIER-P over time.
∂27-Jul-86 1851 FAHLMAN@C.CS.CMU.EDU Proposal #8 Status: Clarifications to DEFCONSTANT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:50:16 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 21:48:26-EDT
Date: Sun, 27 Jul 1986 21:48 EDT
Message-ID: <FAHLMAN.12226153748.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposal #8 Status: Clarifications to DEFCONSTANT
There seems to have been no disagreement with this one. Maybe there are
SOME easy issues after all.
∂27-Jul-86 1902 FAHLMAN@C.CS.CMU.EDU Proposal #9 Status: Variable Name Conflicts
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 19:02:29 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 22:02:48-EDT
Date: Sun, 27 Jul 1986 22:02 EDT
Message-ID: <FAHLMAN.12226156362.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposal #9 Status: Variable Name Conflicts
It was proposed by Gall to extend this to cover LET, LET*, DO, DO*,
FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG. It was argued by
Freeman and later by Masinter that LET* should not be on this list,
since it is not ambiguous what should happen in these contexts.
Fahlman argued in favor of Gall's proposal, on the grounds of
simplicity, the LET* exception being of very dubious value. It was
agreed that this is a matter of taste and that both forms should go to
the technical committee.
---------------------------------------------------------------------------
Proposal #9A:
Clarification:
It is an error for two parameters (including supplied-p and &aux
parameters) in the same lambda list to be represented by the same (EQ)
symbol. This also holds for parameters bound by LET, LET*, DO, DO*,
FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG.
---------------------------------------------------------------------------
Proposal #9B:
Same, but don't include LET*.
---------------------------------------------------------------------------
∂27-Jul-86 1917 FAHLMAN@C.CS.CMU.EDU Staus of proposals 10, 11, and 12
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 19:16:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 22:16:27-EDT
Date: Sun, 27 Jul 1986 22:16 EDT
Message-ID: <FAHLMAN.12226158847.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Common-Lisp@SU-AI.ARPA
Subject: Staus of proposals 10, 11, and 12
Proposal #10: Forms That Allow Declarations
Proposal #11: Contents of Tagbody
Proposal #12: Unique Names For Tags
These proposal seems to have generated no controversy. That's fine with
me!
Someone asked why we allow numbers as tags. This was done because it
seemed harmless and some old code had such things.
∂27-Jul-86 1956 RPG New entries on Common-Lisp
∂27-Jul-86 1730 FAHLMAN@C.CS.CMU.EDU New entries on Common-Lisp
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 17:30:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 20:30:46-EDT
Date: Sun, 27 Jul 1986 20:30 EDT
Message-ID: <FAHLMAN.12226139606.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: rpg@SU-AI.ARPA
Subject: New entries on Common-Lisp
Dick,
Has Common-Lisp-Requests@SU-AI ever been set up? I've heard from
several people who tried mail to that address and failed, before
learning that mail direct to you is the way to get onto the list.
Also, is there any way to arrange for new people on the list to receive
a message stating the ground rules for posting? I know you can't do
anything about the people in Japan and elsewhere who get mail via
rebroadcast. I'm just wondering if this could be done for the people
you put on the list.
Do you think it might be time to split into Common Lisp (random
community messges) and Common Lisp Design mailing lists?
-- Scott
/sub
fahlman@c.cs.cmu.edu
Common-Lisp-Request@SU-AI
Common-Lisp-Request@SU-AI has been set up for years. Note that it is
singular (request) rather than plural (requests). If you send me a
note, I will send it to each new recipient. Currently when I get a
request to be added to Common-Lisp, I send them this first:
``Many of the people who have recently asked to join this list stayed on for
a only week because the volume of mail was too high. Are you prepared for
20 - 30 messages per day on picayune topics?''
I already have a COMMON-LISP-FORUM and COMMON-LISP-FORUM split, which
is not in use. I can set it up as you like. There is some co-ordination
time needed, because there are around 10 re-distribution lists I deal
with, including CSNET-RELAY. I'm at your command.
-rpg-
∂27-Jul-86 2001 FAHLMAN@C.CS.CMU.EDU Proposal #13: Structure Sharing in Arguments
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 20:01:10 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 23:01:24-EDT
Date: Sun, 27 Jul 1986 23:01 EDT
Message-ID: <FAHLMAN.12226167028.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposal #13: Structure Sharing in Arguments
The first part of this seems to have generated no controversy. The
second part, about &REST arguments, has generated a lot of controversy,
in part because it is stated in a way that seems to presuppose that it
is OK to destructively modify most lists.
We seem to be in agreement that &REST args must be true lists, and must
not evaporate when passed upwards; this should be made explicit since it
is an occasional source of confusion, as it was in the discussion of
this issue. (The issue here is not whether implementations currently
comply with this, or even whether they plan to comply with in the
future; the issue is what the language spec requires.)
We also seem to agree that a good rule is that a list should not ever be
destructively modifed unless the programmer understands where it came
from and who else might be holding onto it.
The remaining contentious issue is whether users may assume that the
&REST list in a function is a freshly-consed list, or whether the &REST
list may incorporate the list (or part of it) passed as the last
argument to APPLY.
(Speaking for myself, I initially favored the fresh-consed option as
being cleaner, but Weinreb has convinced me that the APPLY optimization
is important for some kinds of code. I now believe that we should not
outlaw this optimization just so that people can smash &REST args
without thinking about the consequences. We're weighing a real source
of efficiency against the freedom to do something that most programmers
will rarely want to do, and in those cases they can copy to be safe.)
Clarifications:
13A: Specify that the &REST or &BODY argument to a macro may be the very
list from the macro call, and not a copy. Therefore, if this argument
is destructively modified, the originl text of the macro may also be
altered.
13B: Specify explicitly that the &REST argument in a function has
indefinite extent and may, for example, be returned to the function's
caller.
13C: The &REST list in a function is not necessarily a freshly-consed
list. If the function is called with APPLY, the &REST list may share
top-level structure with the last argument to the APPLY. Users should
keep this in mind if they are considering destructive modifications to
such a list.
- OR -
13C': The &REST list in a function is freshly consed upon function entry.
It shares no top-level structure with any pre-existing list.
∂27-Jul-86 2008 masinter.PA@Xerox.COM Re: Proposal #5 status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 86 20:06:46 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 27 JUL 86 20:06:55 PDT
From: masinter.PA@Xerox.COM
Date: 27 Jul 86 20:06:05 PDT
Subject: Re: Proposal #5 status
In-reply-to: FAHLMAN@C.CS.CMU.EDU's message of Sun, 27 Jul 86 18:23 EDT,
<FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>
To: FAHLMAN@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <860727-200655-2208@Xerox>
the reason I gave you only 7 points out of 10 on being a moderator
(besides that I'm a tough grader) is that you took the opportunity under
the guise of "summarizing" to submit another proposal.
I don't like returning 5 values when 3 well chosen ones will do, like
Swiss Army Knife software.
Of all of the proposals, I liked the one which returned any declarations
expanded and the body non-expanded the best; I liked it better than your
new synthesis, where in the common case the parse-body code has to
return more, and the caller has to discard more.
∂27-Jul-86 2008 FAHLMAN@C.CS.CMU.EDU Remaining issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 20:08:19 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 23:05:03-EDT
Date: Sun, 27 Jul 1986 23:05 EDT
Message-ID: <FAHLMAN.12226167693.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Remaining issues
Issue 14 (about THE and VALUES) and the declaration scope stuff are in
a messy state right now. I'll try to sort them out, but it won't happen
for another day or two. I just didn't want you all to panic because you
weren't getting enough mail from me. :-)
∂27-Jul-86 2045 Miller.pa@Xerox.COM Re: Proposal #9B suggested modification
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 86 20:45:13 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 JUL 86 20:45:30 PDT
Date: 27 Jul 86 20:45 PDT
From: Miller.pa@Xerox.COM
Subject: Re: Proposal #9B suggested modification
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
27 Jul 86 22:02 EDT
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <860727-204530-2232@Xerox>
Proposal #9B:
Same, but don't include LET* or DO*
∂27-Jul-86 2046 masinter.PA@Xerox.COM Re: discussion
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 86 20:46:02 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 27 JUL 86 20:46:16 PDT
From: masinter.PA@Xerox.COM
Date: 27 Jul 86 20:45:26 PDT
Subject: Re: discussion
In-reply-to: Your message of Sun, 27 Jul 86 23:12 EDT,
<FAHLMAN.12226168979.BABYL@C.CS.CMU.EDU>
To: FAHLMAN@C.CS.CMU.EDU
cc: common-lisp@su-ai.ARPA
Message-ID: <860727-204616-2233@Xerox>
I reread my message, and lest anyone think otherwise, I think you're
doing a great job as moderator and want to thank you for taking up a
difficult task.
∂27-Jul-86 2126 RPG Common-Lisp-Request@SU-AI
∂27-Jul-86 2021 FAHLMAN@C.CS.CMU.EDU Common-Lisp-Request@SU-AI
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 20:21:38 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 23:15:45-EDT
Date: Sun, 27 Jul 1986 23:15 EDT
Message-ID: <FAHLMAN.12226169640.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Common-Lisp-Request@SU-AI
In-reply-to: Msg of 27 Jul 1986 22:56-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
Dick,
Good, I didn't know if there were technical problems. Maybe we should
discuss the mailing list split with various people at the Lisp
conference, and then decide how and when to handle it.
I'll compose a new welcome message when I get the time.
Thanks,
Scott
∂27-Jul-86 2303 RPG Re: Common Lisp Mailing List
∂27-Jul-86 2206 A79%TAUNIVM.BITNET@WISCVM.ARPA Re: Common Lisp Mailing List
Received: from WISCVM.WISC.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 22:06:40 PDT
Received: from (MAILER)TAUNIVM.BITNET by WISCVM.ARPA on 07/28/86 at
00:06:44 CDT
Received: by TAUNIVM (Mailer X1.23b) id 6428; Mon, 28 Jul 86 08:07:57
IST
Date: Mon, 28 Jul 86 08:03 IST
From: David Sitman <A79%TAUNIVM.BITNET@WISCVM.ARPA>
Subject: Re: Common Lisp Mailing List
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
In-Reply-To: Your message of 27 Jul 86 1153 PDT
I can handle it. I don't mind picayune topics, in fact I'm interested
in all aspects of New Orleans culture.
Please add my name to the mailing list.
David Sitman
/sub
"A79%TAUNIVM.BITNET"@WISCVM.ARPA
Fip
I'm impressed; not many people make the connection with the fippenny bit.
-rpg-
∂28-Jul-86 0814 gls@Think.COM Proposal #13: Structure Sharing in Arguments
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 08:14:33 PDT
Received: from kant by Godot.Think.COM via CHAOS; Mon, 28 Jul 86 11:14:44 edt
Date: Mon, 28 Jul 86 11:15 EDT
From: Guy Steele <gls@Think.COM>
Subject: Proposal #13: Structure Sharing in Arguments
To: DLW@QUABBIN.SCRC.Symbolics.COM, willc%tekchips.tek.csnet@CSNET-RELAY.ARPA,
common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860726135509.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <860728111529.2.GLS@KANT.THINK.COM>
Date: Sat, 26 Jul 86 13:55 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
Date: 23 Jul 86 13:03:26 PDT (Wed)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
in any reasonable implementation the &REST argument will
have been freshly consed.
That's an extremely odd idea. The entire reason that we have &REST
arguments at all is to avoid the need for consing the list. Had we
intended for the list to be freshly consed, we would never have
implemented &REST at all; we'd have just let the caller cons up a list
and pass it as a regular argument.
Well, Dan, maybe it would be more accurate to say that the entire reason
for having &REST arguments is that we want to have N-ary functions such
as + but find the old MacLISP LEXPR ("NARGS") mechanism unappealing.
The entire reason, in turn to want &REST argument list-structure to have
dynamic extent is to avoid consing.
In the past I argued that a sufficiently clever compiler (SCC) could do
some data flow analysis and recognize when &REST arguments were being
used only in certain "safe" ways (such as being fed to a DOLIST) and
avoid consing in that case. I now lean more toward also having
something like the NARGS mechanism, yukky as it was.
--Guy
∂28-Jul-86 0912 LOOSEMORE@UTAH-20.ARPA proposal #6 (&body parsing)
Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 09:11:05 PDT
Date: Mon 28 Jul 86 10:10:29-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: proposal #6 (&body parsing)
To: common-lisp@SU-AI.ARPA
Message-ID: <12226310687.19.LOOSEMORE@UTAH-20.ARPA>
Two questions:
(1) If &rest and &body are not going to be the same anymore, will they
remain mutually exclusive? (I can imagine some situations where you might
want both a "parsed" and "unparsed" body -- although you could call
parse-body yourself instead to get this effect.)
(2) Will we continue to allow both &body and &key together? This does
not make a great deal of sense to me, as a list of keyword/value pairs is
not what one typically thinks of as a "body".
-Sandra
-------
∂28-Jul-86 0922 LOOSEMORE@UTAH-20.ARPA proposal #5 (parse-body)
Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 09:21:49 PDT
Date: Mon 28 Jul 86 10:21:58-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: proposal #5 (parse-body)
To: common-lisp@SU-AI.ARPA
Message-ID: <12226312777.27.LOOSEMORE@UTAH-20.ARPA>
Returning 5 values from parse-body seems like overkill to me. I can't think
of any examples where it wouldn't be acceptable to return the declarations
expanded and the body not.
I'd also like to second the proposal to change the syntax to make the
doc-allowed-p argument required and only the environment argument optional.
-Sandra
-------
∂28-Jul-86 0944 hoey@nrl-aic Re: Proposal #13: Structure Sharing in Arguments
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 09:44:07 PDT
Date: 28 Jul 1986 12:00:48 EDT (Mon)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: Proposal #13: Structure Sharing in Arguments
To: Common-Lisp@SU-AI.ARPA
Message-Id: <522950449/hoey@nrl-aic>
In-Reply-To: Daniel L. Weinreb's message of Sat, 26 Jul 86 1712 EDT
I would ask for freshly consed &REST lists for all functions, because
the alternative is too bug-prone. I am not convinced by the argument
against consing APPLY args:
Date: Sat, 26 Jul 86 17:12 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
... One of the things that's very useful to do with &rest
arguments is to "pass them on down" to further functions,
using apply. Having used &rest for a long time, we've found
this usage pattern to be extremely common. For example, we
have many functions that take several arguments, followed by
a FORMAT control string, followed by an arbitrary number of format
arguments. We have programs that do this passing-down to many levels of
depth. By requiring that the entire list be copied for every such call,
the cost of function calling is raised very considerably....
I believe this sort of programming style is best done by passing the
&REST arg itself to the lower-level functions, rather than by calling
APPLY. In the case of FORMAT, the modification is simply to use "~?".
I do not intend this argument to apply to macro arguments. I lean
towards the view that macro arguments should NOT be consed--that the
&REST argument to a macro should be the list itself.
Dan Hoey
∂28-Jul-86 0953 RPG Possible New Issues
∂26-Jul-86 2146 FAHLMAN@C.CS.CMU.EDU Possible New Issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 21:46:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 27 Jul 86 00:46:44-EDT
Date: Sun, 27 Jul 1986 00:46 EDT
Message-ID: <FAHLMAN.12225924058.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: fahlman@C.CS.CMU.EDU
Subject: Possible New Issues
In-reply-to: Msg of 26 Jul 1986 23:19-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
Dick,
The change to MV-BIND is something I opposed five years ago
(successfully), and still am not crazy about, though my attitude is no
longer "over my dead body". Presumably we require &allow-other-keys, et
al? &rest conses the extra values -- everyone would have to do some
clever optimizing in order to avoid consing values that they plan to
throw away (since we don't have &REST IGNORE).
If are sure you want to propose this, I'll put it on the list and
introduce it when a new fight seems tolerable. I think you'll see a
rather heated discussion between the people who say "of course the
language is more elegant this way" and the people who actually are faced
with implementing this. I'm probably less opposed to this than before
because it would be Rob's problem, not mine.
By way of classification, I would say that this would break some user
code that now depends on excess values beign dropped and unsupplied
values turning to NIL. I guess one could fix this mechanically by
turning all MV-BIND lists (x y z) into (&optional x y z &rest ignore).
Is that right? Should we propose special semantics for variables named
IGNORE at the same time? A lot of people seem to want this.
My reaction to the special proposal is that this is many steps over the
border for Common Lisp 87 (or whatever). It breaks lots of code in ugly
ways that could only be fixed by a person or a rather smart code-walker.
If I thought that such radical changes were in order, I would go one
step farther: a special ref to X would not be made by saying "X", but
only by saying (DYNAMIC X), for which we define a read macro such as $X.
Any binding form can bind a special value, but again the variable is
indicated as (DYNAMIC X) or $X rather than just X, right there on the
spot. The anomalous SPECIAL declaration woudl go away altogether.
The next time I do a language for my own enjoyment, this is how it's
going to work, but I think it's too late for Common Lisp.
Do you REALLY want to pursue this now?
-- Scott
∂28-Jul-86 1147 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #9 Status: Variable Name Conflicts
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 11:46:30 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24588; Mon 28-Jul-86 11:52:07 EDT
Date: Mon, 28 Jul 86 11:52 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #9 Status: Variable Name Conflicts
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226156362.BABYL@C.CS.CMU.EDU>
Message-ID: <860728115240.4.DCP@FIREBIRD.SCRC.Symbolics.COM>
Doing the multiple variable name check for PROGV would require an N↑2
check at runtime instead of compile time. Consider as an extreme
(multiple-value-bind (vars1 vals1)
(get-some-vars-and-vals)
(multiple-value-bind (vars2 vals2)
(get-some-more-vars-and-vals-that-can-override)
(progv (append vars1 vars2)
(append vals1 vals1)
...implicit-progn...)))
One could counter argue that I should be using two PROGVs. I will
counter-counter it probably shouldn't make an iota of difference.
ps: I only recently read the mail about etiquette.
pps: Some context is needed. There was one message about DEFCONSTANT
saying everybody agreed. Since I don't have the proposals tacked to my
wall, I could barely remember what it was we were all agreeing about.
It also took a while to recache what Proposal #9 was all about.
∂28-Jul-86 1147 DCP@QUABBIN.SCRC.Symbolics.COM Re: REDUCE args
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 11:44:47 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24559; Mon 28-Jul-86 09:48:45 EDT
Date: Mon, 28 Jul 86 09:49 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: REDUCE args
To: Skef Wholey <Skef@THINK.COM>, Guy Steele <gls@THINK.COM>,
DCP@QUABBIN.SCRC.Symbolics.COM, NGALL@G.BBN.COM,
ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860725121309.3.SKEF@WENCESLAS.THINK.COM>,
<860725175113.5.GLS@IGNATIUS.THINK.COM>
Message-ID: <860728094914.9.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Fri, 25 Jul 86 12:13 EDT
From: Skef Wholey <Skef@Think.COM>
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Fri, 25 Jul 86 09:55 EDT
From: Skef Wholey <Skef@Think.COM>
In the meantime, you can of course do something like:
(reduce #'fun (map 'vector #'key sequence))
Somebody brought up this method the last time. I had at least two
reactions: (1) It doesn't really express the intent of the programmer,
and (2) I don't care what kind of machine you are on, you should care
about efficiency and consing.
However, it is very easy to write a compiler transform that turns the
above into a call to a hidden function that does what the above does
without consing. The sequence functions are the most obvious, easiest
target for source-level optimization in a Common Lisp compiler. If the
above were listed as an idiom in the manual, then such optimizers might
appear in implementations. This is a real alternative, not some
pie-in-the-sky "a smart compiler could..." argument.
I agree this is a real alternative. The in-English thing being
expressed is "compute the sum of the car of each element of the
sequence." To me "compute the sum of ... the sequence"
translates to (reduce #'+ sequence ...) and "the car of" translates to
:KEY #'CAR. To you "Compute the sum of" translates to (reduce #'+ ...)
and "the car of the sequcnce" translates to (map 'vector #'CAR
sequence). Both translations are valid and both are probably correct
given today's ideas about programming. Here's my justification for
mine: My high level goal is to do something to a sequence. Since I am
only doing one thing to the sequence, I want only one sequence operation
to be expressed in my code.
I feel the argument about consistent use of :KEY, :TEST, and :TEST-NOT
still holds. I don't object to adding a field selector argument to
REDUCE, but I don't think that it should be called :KEY. One might
introduce a new function, REDUCE-FIELD (or whatever), or a new keyword.
I've thought about this a little. :TEST/:TEST-NOT should apply before
the key is extracted. We can either declare that this test must
validiate the key (and must therefore also know how to extract it), or
we can add a :KET-TEST arg, defaulting to #'TRUTH (not #'IDENTITY !),
which validates the key. Therefore, you could get
(defun sum-numeric-cadrs-whose-car-is (expected-car sequence)
(reduce #'+ sequence
:test #'(lambda (element) (eq (car element) expected-car))
:key #'cadr
:key-test #'numberp))
Date: Fri, 25 Jul 86 17:51 EDT
From: Guy Steele <gls@Think.COM>
Date: Fri, 25 Jul 86 11:39 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Fri, 25 Jul 86 09:55 EDT
From: Skef Wholey <Skef@Think.COM>
In the meantime, you can of course do something like:
(reduce #'fun (map 'vector #'key sequence))
Now-living-on-a-3600-and-not-caring-too-much-about-consing-or-81-character-lines,
Somebody brought up this method the last time. I had at least two
reactions: (1) It doesn't really express the intent of the programmer,
and (2) I don't care what kind of machine you are on, you should care
about efficiency and consing.
I buy your argument (2), but (1) seems to be a bit spurious.
Why isn't the intent "take all those keys and reduce them"?
If that is the intent, why can't that be expressed as
"(take all those keys) and (reduce them)"? Is it that
you had rather in mind "reduce all them thar keys"
and don't consider the other an equivalent formulation?
I think I explained this above. Indeed, (1) probably is a bit spurious.
It depends on how you view the problem.
∂28-Jul-86 1153 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #5 status
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 11:53:09 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24585; Mon 28-Jul-86 11:39:04 EDT
Date: Mon, 28 Jul 86 11:39 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #5 status
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>
References: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>,
<860727-200655-2208@Xerox>
Message-ID: <860728113936.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sun, 27 Jul 1986 18:23 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Here is the first of the status reports on pending proposals. This is
culled from a lot of old mail; my apologies in advance if I missed some
key suggestion. I suggest that we use this as the starting point for
further discussion of this issue (and similarly with the others) and
that we try to converge on a final set of proposals for the technical
committee fairly soon. All of these summaries are from me as moderator;
where I have seen fit in inject one of my personal opinions on some
technical matter, that is marked.
-- Scott
---------------------------------------------------------------------------
There seems to be no opposition to the idea of PARSE-BODY per se. There
have been numerous suggestions about the exact form of the arguments and
return values, and I have incorporated most of these suggestions into
revised proposal 5A below: making the environment and doc-p arguments
optional, reordering the returns into what some consider a more natural
order, and returning the declarations as a combined list of
decl-specs (as the book calls them), without the surrounding DECLAREs.
One suggestion by Nick Gall is to add a declaration-allowed-p form. If
this is NIL, then PARSE-BODY has the task of ensuring that the body does
NOT contain declarations. Some people have responded that this
functionality does not belong in PARSE-BODY. (Speaking as SEF, I agree
with this view. Nick is free to pursue this further if he wants to,
but I suspect that the idea is not going anywhere.)
One complex issue is whether the body should be returned in its original
form or with any macro-expansion that was computed while looking for
initial decls replacing the original body forms. (There will only be
one of these, since the first non-declaration stops the expansion.) One
would like to avoid doing the work of expansion a second time, but
sometimes it is necessary to get at the original body. In 5A below, I
propose a solution that may get get the best of both worlds: the body is
returned in original form, but there are two additional return values,
one indicating the availability of a macro-expansion for the first body
form, and the other being that expansion. (Two extra values are
necessary because the macro might perversely expand into NIL after doing
a lot of work.)
---------------------------------------------------------------------------
Proposal #5A: PARSE-BODY
Extension:
[I somewhat agree with Masinter.]
Add a new function:
(PARSE-BODY body &optional environment documentation-allowed-p)
The default for environment is NIL, meaning to use a null lexical
environment. The default for documentation-allowed-p is NIL, meaning
that this form is NOT allowed to have a documentation string.
Can somebody PLEASE give me an example of (a) where this is useful and
(b) where this makes a difference? I can think of one example where it
can make a difference, but it also shows that this argument is
misguided. There are probably others in the same class. The example
is multiple-value-bind, which takes declarations but does not take a
doc-string. Now, a doc-string isn't illegal; a string doesn't get
interpreted as a string. Consider these cases:
(multiple-value-bind (a b)
(compute)
(declare (ignore a b))
"frob")
This is completely reasonable. "frob" isn't a doc-string (even if doc
strings were "allowed") because there aren't any forms following.
(multiple-value-bind (a b)
(compute)
(declare (ignore a b))
"frob"
(compute-something-else))
This is still valid. It isn't the greatest style, but there is nothing
wrong with it. "frob" is a constant compiled for effect. As I
understand the current proposal, calling parse-body on the above "body"
would result in an error, which is wrong. The argument should be called
no-doc-string-p. It directs the parser to >>stop parsing<< when it
encounters a doc-string; it doesn't tell the parser to signal an error.
(multiple-value-bind (a b)
(compute)
(declare (ignore a))
"frob"
(declare (ignore b))
(compute-something-else))
This IS an error, but since multiple-value-bind doesn't take
doc-strings, it will stop parsing when it gets to "frob" and you simply
have to let the implicit-progn handler figure it out.
PARSE-BODY extracts the documentation string and declarations from BODY,
expanding initial macros as necessary to determine if they contain
declarations. It returns five values:
[A lot of rationale is missing.]
1. A documentation string (or NIL if none is present).
Why isn't the body first. What if there is more than one doc string?
2. A combined list of declaration specs, extracted from all
DECLARE forms found at the start of the body, whether present in the
body itself or obtained via macro-expansion.
This isn't explicit enough. Do I get
((declare (ignore a))
(declare (ignore b)))
or do I get
(declare (ignore a)
(ignore b))
or do I get
((ignore a)
(ignore b))
?? I assume somebody has convinced themselves that the ordering or
separation of declares has no semantic meaning in CL?
3. The remainder of the BODY argument, following any initial
doc-strings, declarations, or forms that expand into declarations.
4. The macro-expansion for the first form in return value 3, if any.
Why the macroexpansion of the first form of the body? Why not the body
with the first form possibly expanded? Why should I always
,first-form-expanded ,@(rest body)
instead of
,@expanded-body
??
5. T if return 4 is a valid macro-expansion for the first form
in return 3, NIL otherwise.
What is an invalid macro expansion?
Why not toss in the kitchen sink? It looks to me like
design-by-committee disease is striking. What functionality is useful
and needed, and what do we need to express it?
∂28-Jul-86 1155 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #5 status
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 11:54:30 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24586; Mon 28-Jul-86 11:39:35 EDT
Date: Mon, 28 Jul 86 11:40 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #5 status
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>
References: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>,
<860727-200655-2208@Xerox>
Supersedes: <860728113936.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860728114007.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sun, 27 Jul 1986 18:23 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Here is the first of the status reports on pending proposals. This is
culled from a lot of old mail; my apologies in advance if I missed some
key suggestion. I suggest that we use this as the starting point for
further discussion of this issue (and similarly with the others) and
that we try to converge on a final set of proposals for the technical
committee fairly soon. All of these summaries are from me as moderator;
where I have seen fit in inject one of my personal opinions on some
technical matter, that is marked.
-- Scott
---------------------------------------------------------------------------
There seems to be no opposition to the idea of PARSE-BODY per se. There
have been numerous suggestions about the exact form of the arguments and
return values, and I have incorporated most of these suggestions into
revised proposal 5A below: making the environment and doc-p arguments
optional, reordering the returns into what some consider a more natural
order, and returning the declarations as a combined list of
decl-specs (as the book calls them), without the surrounding DECLAREs.
One suggestion by Nick Gall is to add a declaration-allowed-p form. If
this is NIL, then PARSE-BODY has the task of ensuring that the body does
NOT contain declarations. Some people have responded that this
functionality does not belong in PARSE-BODY. (Speaking as SEF, I agree
with this view. Nick is free to pursue this further if he wants to,
but I suspect that the idea is not going anywhere.)
One complex issue is whether the body should be returned in its original
form or with any macro-expansion that was computed while looking for
initial decls replacing the original body forms. (There will only be
one of these, since the first non-declaration stops the expansion.) One
would like to avoid doing the work of expansion a second time, but
sometimes it is necessary to get at the original body. In 5A below, I
propose a solution that may get get the best of both worlds: the body is
returned in original form, but there are two additional return values,
one indicating the availability of a macro-expansion for the first body
form, and the other being that expansion. (Two extra values are
necessary because the macro might perversely expand into NIL after doing
a lot of work.)
---------------------------------------------------------------------------
Proposal #5A: PARSE-BODY
Extension:
[I somewhat agree with Masinter.]
Add a new function:
(PARSE-BODY body &optional environment documentation-allowed-p)
The default for environment is NIL, meaning to use a null lexical
environment. The default for documentation-allowed-p is NIL, meaning
that this form is NOT allowed to have a documentation string.
Can somebody PLEASE give me an example of (a) where this is useful and
(b) where this makes a difference? I can think of one example where it
can make a difference, but it also shows that this argument is
misguided. There are probably others in the same class. The example
is multiple-value-bind, which takes declarations but does not take a
doc-string. Now, a doc-string isn't illegal; a string doesn't get
interpreted as a string. Consider these cases:
(multiple-value-bind (a b)
(compute)
(declare (ignore a b))
"frob")
This is completely reasonable. "frob" isn't a doc-string (even if doc
strings were "allowed") because there aren't any forms following.
(multiple-value-bind (a b)
(compute)
(declare (ignore a b))
"frob"
(compute-something-else))
This is still valid. It isn't the greatest style, but there is nothing
wrong with it. "frob" is a constant compiled for effect. As I
understand the current proposal, calling parse-body on the above "body"
would result in an error, which is wrong. The argument should be called
no-doc-string-p. It directs the parser to >>stop parsing<< when it
encounters a doc-string; it doesn't tell the parser to signal an error.
(multiple-value-bind (a b)
(compute)
(declare (ignore a))
"frob"
(declare (ignore b))
(compute-something-else))
This IS an error, but since multiple-value-bind doesn't take
doc-strings, it will stop parsing when it gets to "frob" and you simply
have to let the implicit-progn handler figure it out.
PARSE-BODY extracts the documentation string and declarations from BODY,
expanding initial macros as necessary to determine if they contain
declarations. It returns five values:
[A lot of rationale is missing.]
1. A documentation string (or NIL if none is present).
Why isn't the body first. What if there is more than one doc string?
2. A combined list of declaration specs, extracted from all
DECLARE forms found at the start of the body, whether present in the
body itself or obtained via macro-expansion.
This isn't explicit enough. Do I get
((declare (ignore a))
(declare (ignore b)))
or do I get
(declare (ignore a)
(ignore b))
or do I get
((ignore a)
(ignore b))
?? I assume somebody has convinced themselves that the ordering or
separation of declares has no semantic meaning in CL?
3. The remainder of the BODY argument, following any initial
doc-strings, declarations, or forms that expand into declarations.
4. The macro-expansion for the first form in return value 3, if any.
Why the macroexpansion of the first form of the body? Why not the body
with the first form possibly expanded? Why should I always
,first-form-expanded ,@(rest body)
instead of
,@expanded-body
??
5. T if return 4 is a valid macro-expansion for the first form
in return 3, NIL otherwise.
What is an invalid macro expansion? What would this possibly be used
for? When could it possibly make a difference?
Why not toss in the kitchen sink? It looks to me like
design-by-committee disease is striking. What functionality is useful
and needed, and what do we need to express it?
∂28-Jul-86 1220 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #7 Status: TYPE-SPECIFIER-P
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:17:35 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24581; Mon 28-Jul-86 11:09:39 EDT
Date: Mon, 28 Jul 86 11:10 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #7 Status: TYPE-SPECIFIER-P
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226153071.BABYL@C.CS.CMU.EDU>
Message-ID: <860728111011.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sun, 27 Jul 1986 21:44 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Several people have proposed that this be restricted to take only
symbols, since that is the most important use, and it becomes hard to
specify exactly what things must be checked for correctness in the
myriad of more complex cases. (Speaking for myself, I favor this
change.) This is proposed in 7A below.
This restriction potentially removes some of its usefulness. I can
imagine
(defun typep (object type-specifier)
(assert (type-specifier-p type-specifier) (type-specifier)
"~S is not a valid type-specifier" type-specifier)
...etc...)
and therefore it can't be restricted to a symbol and indeed must do full
semantic checking of the type specifier to make sure it is OK.
Therefore, (type-specifier-p '(complex array array)) is legal and
returns NIL.
If someone wants to argue in favor of handling the more complex
type-specifiers as well, I would ask you to provide a specific and
detailed proposal for exactly what things must be examined in each case.
It returns T if it is a meaningful second argument to TYPEP and NIL if
not. Is that specific enough?
It was also suggested that we do this by (TYPEP arg 'TYPE-SPECIFIER), but
some opposition to this idea has also been expressed, on the grounds
that TYPE-SPECIFIER is not really a type in the usual sense. Also, if
we did this, it would be awkward to restrict the argument to being a
symbol.
---------------------------------------------------------------------------
Proposl #7A: TYPE-SPECIFIER-P
Proposed extension:
Add a new function (TYPE-SPECIFIER-P arg), where ARG must be a symbol.
If ARG is a valid type specifier, this returns T; else it returns NIL.
Note that the use of DEFSTRUCT and DEFTYPE can change the behavior of
TYPE-SPECIFIER-P over time.
∂28-Jul-86 1222 DCP@STONY-BROOK.SCRC.Symbolics.COM Staus of proposals 10, 11, and 12
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:20:36 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 66682; Mon 28-Jul-86 11:57:11 EDT
Date: Mon, 28 Jul 86 11:55 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Staus of proposals 10, 11, and 12
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226158847.BABYL@C.CS.CMU.EDU>
Message-ID: <860728115558.5.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sun, 27 Jul 1986 22:16 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Proposal #10: Forms That Allow Declarations
[This] proposal seems to have generated no controversy. That's fine with
me!
I did question the need/usefullness of allowing declarations in
MACROLET. Nobody has responded and I still can't think of any.
∂28-Jul-86 1224 FAHLMAN@C.CS.CMU.EDU Proposal #9 Status: Variable Name Conflicts
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:16:17 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 28 Jul 86 15:06:41-EDT
Date: Mon, 28 Jul 1986 15:06 EDT
Message-ID: <FAHLMAN.12226342735.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal #9 Status: Variable Name Conflicts
In-reply-to: Msg of 28 Jul 1986 11:52-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
Doing the multiple variable name check for PROGV would require an N↑2
check at runtime instead of compile time.
So don't check. This "is an error", not "signals an error". Besides,
PROGV is a special-case hack that is inherently slow compared tot eh
things people actually use a lot.
ps: I only recently read the mail about etiquette.
Please read it a couple more times and then meditate on how it might
apply to this batch of posts you have just sent.
-- Scott
∂28-Jul-86 1220 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #13: Structure Sharing in Arguments
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:15:21 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24557; Mon 28-Jul-86 09:31:04 EDT
Date: Mon, 28 Jul 86 09:31 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #13: Structure Sharing in Arguments
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226167028.BABYL@C.CS.CMU.EDU>
Message-ID: <860728093136.8.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sun, 27 Jul 1986 23:01 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
The first part of this seems to have generated no controversy. The
second part, about &REST arguments, has generated a lot of controversy,
in part because it is stated in a way that seems to presuppose that it
is OK to destructively modify most lists.
We seem to be in agreement that &REST args must be true lists, and must
not evaporate when passed upwards
or stored in stable storage
; this should be made explicit since it
is an occasional source of confusion, as it was in the discussion of
this issue. (The issue here is not whether implementations currently
comply with this, or even whether they plan to comply with in the
future; the issue is what the language spec requires.)
We also seem to agree that a good rule is that a list should not ever be
destructively modifed unless the programmer understands where it came
from and who else might be holding onto it.
The remaining contentious issue is whether users may assume that the
&REST list in a function is a freshly-consed list, or whether the &REST
list may incorporate the list (or part of it) passed as the last
argument to APPLY.
(Speaking for myself, I initially favored the fresh-consed option as
being cleaner, but Weinreb has convinced me that the APPLY optimization
is important for some kinds of code. I now believe that we should not
outlaw this optimization just so that people can smash &REST args
without thinking about the consequences. We're weighing a real source
of efficiency against the freedom to do something that most programmers
will rarely want to do, and in those cases they can copy to be safe.)
It is important that programmers not avoid the &REST feature because
they believe it is universally expensive in time and storage.
Clarifications:
13A: Specify that the &REST or &BODY argument to a macro may be the very
list from the macro call, and not a copy. Therefore, if this argument
is destructively modified, the originl text of the macro may also be
altered.
13B: Specify explicitly that the &REST argument in a function has
indefinite extent and may, for example, be returned to the function's
caller.
13C: The &REST list in a function is not necessarily a freshly-consed
list. If the function is called with APPLY, the &REST list may share
top-level structure with the last argument to the APPLY. Users should
keep this in mind if they are considering destructive modifications to
such a list.
- OR -
13C': The &REST list in a function is freshly consed upon function entry.
It shares no top-level structure with any pre-existing list.
My opinion still stands: it depends on how hard you look. I still think
13B and 13C are in conflict:
(defun copy-list (list)
(apply #'list list))
(defun list (&rest list)
list)
I think 13C' implies global inefficiency and may detract programmers
from using &REST.
I think the necessary >>semantics<< are 13B and 13C', and that a
compiler that can prove the &REST list is being in only downward ways
(all destructive modification should be considered "upward") is allowed
to keep the list "consed on the stack" in the implementations that work
that way, or "shared with last arg to APPLY" in the implementatins that
work that way as well/instead. &KEY is essentially a standard deconding
of an &REST arg, and &KEY is completely downward and never (unless
accompanied by an explicit &REST) needs to freshly cons the implicit
&REST arg.
We may want to decide on the name of a
declaration to override the case when the compiler can't figure it out.
(defun 3arg-format (stream string args)
(apply #'format stream string args))
(defun send-it (string &rest args)
(declare (sys:downward-&rest-arg))
(3arg-format t string args))
∂28-Jul-86 1224 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #6 Status: Parsing in &BODY
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:16:31 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24563; Mon 28-Jul-86 09:58:37 EDT
Date: Mon, 28 Jul 86 09:59 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #6 Status: Parsing in &BODY
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226145207.BABYL@C.CS.CMU.EDU>
Message-ID: <860728095907.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Sun, 27 Jul 1986 21:01 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Nobody seems to oppose this. One or two people have questioned its
usefulness, but the discussion we had on this a year or so ago
demonstrated considerable demand for this as an alternative to making
users handle environment objects directly.
Most people who commented on this prefer KMP's proposed syntax, though
there seems to be little enthusiasm for the inclusion of default and
supplied-p values. (Speaking for myself, I'm happy to go along with
this if we don't get into default/supplied-p complexities.) So, we have
a revised proposal:
---------------------------------------------------------------------------
Proposal #6A: Parsing in &BODY
Extension:
Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
(DEFMACRO name (... &BODY body-var [declarations-var [doc-string-var]]) ...)
If DECLARATIONS-VAR is present, it means to give the original body to
PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is
present)
This will break existing code. One can no longer write
(defmacro defun (name bvl &body body) ...)
because doc-string-var is not supplied and therefore PARSE-BODY, given
the direction people want to be taking it, will err because
documentation-allowed-p will be false.
and then bind the variables to the corresponding values
returned by PARSE-BODY. This is purely a syntactic convenience for the
user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then
call PARSE-BODY himself.
Sorry for the broken record: A body is a body is a body is a body... A
body has declarations and a doc string.
Note: This extension is proposed only for &BODY, not for &REST, so &BODY
will no longer be exactly equivalent to &REST in a DEFMACRO arglist.
∂28-Jul-86 1301 Masinter.pa@Xerox.COM Re: Proposal #7 Status: TYPE-SPECIFIER-P
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:41:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 JUL 86 12:36:23 PDT
Date: 28 Jul 86 11:52 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Proposal #7 Status: TYPE-SPECIFIER-P
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
27 Jul 86 21:44 EDT
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <860728-123623-2787@Xerox>
On some further thought, TYPE-SPECIFIER-P is ambiguous in some cases
where the argument is a symbol:
Suppose you have
(deftype relatively-prime-to (n) `(satisfies (lambda (x) (= 1 (gcd x
,n)))))
In this case, relatively-prime-to by itself is not "a valid type
specifier".
(relatively-prime-to 10) is a valid type specifier, and
(relatively-prime-to t) is not.
Is the intent "is this something I can hand to typep?" If so, it would
be false for "relatively-prime-to". If the intent is "does this *name* a
type-specifier" then we could allow it, but the usefulness of such a
thing is unclear to me.
If the notion is "does this symbol name a class of Common Lisp objects,"
there may be a better way to get at this (e.g., CommonLoops defines
classes and it makes sense to ask, is there a class with this name).
With all of that, I'd argue against adding this, at this time, for the
following reasons:
a) it doesn't have well defined semantics, and attempts to narrow the
range in order to avoid ambiguity haven't succeeded
b) no one has offered a prototypical implementation, or even suggested
that they had an implementation for their common lisp against which we
could measure its use
c) this is a request for a feature, but there's little evidence that
there are significant, meaningful, portable uses for it. (Portable = a
program written with one Common Lisp's version is likely to run with
another Common Lisp's version.)
d) of all of the proposals to consider, proposals to add new constructs
should get much lower priority than those to clarify or standardize
current constructs.
e) there is another proposal (before the Object Oriented Programming
committee in this case) which satisfies at least part of the original
requirement in a different way.
∂28-Jul-86 1358 RICE@SUMEX-AIM.ARPA Proposal #7A - Type-Specifier-P
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 13:17:11 PDT
Date: Mon 28 Jul 86 11:39:52-PDT
From: James Rice <Rice@SUMEX-AIM.ARPA>
Subject: Proposal #7A - Type-Specifier-P
To: Common-Lisp@SU-AI.ARPA
Message-ID: <12226337882.76.RICE@SUMEX-AIM.ARPA>
It seems to me that the proposed function Type-Specifier-P
is in fact Type-Name-P, since it cannot be called with an
arbitrary CL type specifier. Perhaps its name should be
changed accordingly.
Personally, I would prefer to have (Typep foo 'Type-Specifier) -
but then again I'd like all types to be represented by objects
of type Type too.
Rice
-------
∂28-Jul-86 1416 Masinter.pa@Xerox.COM Re: PARSE-BODY
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 14:01:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 JUL 86 14:02:17 PDT
Date: 28 Jul 86 13:43 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: PARSE-BODY
To: common-lisp@sail.stanford.edu
Message-ID: <860728-140217-2923@Xerox>
I am (now) opposed to adding PARSE-BODY to the Common Lisp standard (as
long as the parse-body option is added to the macro expansion argument
list) for the following reasons:
a) it is of little general utility
Given the addition of &body variables for macros, I can think of no
examples where I would want to directly call parse-body instead of just
using the macro-expansion option. (I currently have lots of examples
that call parse-body, but they're all in macros that could use the new
&body options instead.)
b) it is controversial
While every implementation will have SOMETHING like parse-body (if only
to implement the handing of macro arguments) there seems to be little
agreement on what its arguments might be or what values it might return.
It would seem that every implementation wants something slightly
different (e.g., it depends on whether you cache macro translations as
for whether you want to save the macro translation & the work of
obtaining it or recompute it.)
c) it isn't very simple
(This is isn't a simple argument to make, unfortunately.) The value of
features is inversly proportional to the complexity of their interfaces.
Functions that have a "process-it-this-way-p" arguments and "returns 3
values, but maybe just the first" should be viewed with suspicion, that
they don't represent the "true" interface to what is going on in the
system. That is, "parse-body" is just a piece of some more complex
processing of macros, arguments & bodies that is part of the language
writers toolkit, that isn't very isolated. Motivating it (what's this
for?) would be difficult without a lot more context.
∂28-Jul-86 1524 VERACSD@A.ISI.EDU Re: Remaining issues
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 15:11:26 PDT
Date: 28 Jul 1986 17:39-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Re: Remaining issues
From: VERACSD@A.ISI.EDU
To: Fahlman@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[A.ISI.EDU]28-Jul-86 17:39:15.VERACSD>
In-Reply-To: <FAHLMAN.12226167693.BABYL@C.CS.CMU.EDU>
Please explain what ":-)" means. I've been curious about it for
a while, especially after I saw a graphical joke using it.
Thanks.
∂28-Jul-86 1624 Masinter.pa@Xerox.COM Re: Proposal #6 Status: Parsing in &BODY
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 16:24:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 JUL 86 16:19:42 PDT
Date: 28 Jul 86 15:49 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Proposal #6 Status: Parsing in &BODY
In-reply-to: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>'s message
of Mon, 28 Jul 86 09:59 EDT
To: DCP@QUABBIN.SCRC.Symbolics.COM
cc: common-lisp@su-ai.ARPA
Message-ID: <860728-161942-3071@Xerox>
It was unclear to me whether you are for the &body extension, against
it, or have an alternative to propose.
I don't think anyone was proposing that
(defmacro defun (name bvl &body body)
...)
would call parse-body. Only
(defmacro defun (name bvl &body body decls)
...)
would call parse-body.
I suggest rephrasing Proposal #6A to removing the reference to
"parse-body", since there's some disagreement about what that function
might be. E.g.:
Proposal #6A':
Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
(DEFMACRO name (... &BODY body-var [declarations-var [doc-string-var]])
...)
If declarations-var is present, then, the original body is parsed,
looking for declarations and, when doc-string-var is present, for
documentation strings. Body-var is bound to the remaining body, while
declarations-var is bound to a list of (declare ...) forms and (when
present) doc-string-var to the first documentation string found.
During the course of processing the original body, macros are expanded
to see if they expand into declarations, although the macro expansion
itself is not kept if no declarations are found. Note that a
documentation string cannot be the @i[last] element in a body, according
to the syntax on p. xxx.
∂28-Jul-86 1624 Masinter.pa@Xerox.COM Re: Proposal #9: Variable Name Conflicts
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 16:24:40 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 JUL 86 16:23:39 PDT
Date: 28 Jul 86 15:52 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Proposal #9: Variable Name Conflicts
To: common-lisp@SU-AI.ARPA
Message-ID: <860728-162339-3074@Xerox>
I'd like to request that discussion of this proposal be suspended until
after the question of the scope of declarations gets considered.
My reason is that one of the primary arguments against duplicate names
in a binding form is the ambiguity of referent for declarations. Some of
the proposals for declaration scoping would remove the ambiguity.
∂28-Jul-86 1830 ALAN@AI.AI.MIT.EDU Proposal #9: Variable Name Conflicts
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 18:30:15 PDT
Date: Mon, 28 Jul 86 21:31:15 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Proposal #9: Variable Name Conflicts
To: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 28 Jul 86 15:52 PDT from Masinter.pa at Xerox.COM
Message-ID: <[AI.AI.MIT.EDU].76807.860728.ALAN>
Date: 28 Jul 86 15:52 PDT
From: Masinter.pa at Xerox.COM
I'd like to request that discussion of this proposal be suspended until
after the question of the scope of declarations gets considered.
My reason is that one of the primary arguments against duplicate names
in a binding form is the ambiguity of referent for declarations. Some of
the proposals for declaration scoping would remove the ambiguity.
Funny, I was going to suggest exactly the opposite. I was going to suggest
that we delay the declarations issue until after we decide the scoping
issue. The two clearly have an interaction, the question is do you want
the crufty rules for declarations to drive the scoping rules, or vice
versa? My instincts say that the variable scoping rules should be
clarified first, but clearly other people may see things the other way, so
perhaps we can do no better than to continue to deal with them both
simultaneously.
∂28-Jul-86 1839 FAHLMAN@C.CS.CMU.EDU proposal #6 (&body parsing)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 18:38:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 28 Jul 86 21:39:07-EDT
Date: Mon, 28 Jul 1986 21:39 EDT
Message-ID: <FAHLMAN.12226414192.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: proposal #6 (&body parsing)
In-reply-to: Msg of 28 Jul 1986 12:10-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
(1) If &rest and &body are not going to be the same anymore, will they
remain mutually exclusive? (I can imagine some situations where you might
want both a "parsed" and "unparsed" body -- although you could call
parse-body yourself instead to get this effect.)
I think they should remain mutually exclusive. As you say, the user can
always call parse-body directly, in the very rare case where both forms
are needed.
(2) Will we continue to allow both &body and &key together? This does
not make a great deal of sense to me, as a list of keyword/value pairs is
not what one typically thinks of as a "body".
One would probably never want to use &body and &key together, but I see
no reason to go out of our way to outlaw this.
-- Scott
∂28-Jul-86 1848 FAHLMAN@C.CS.CMU.EDU [gls: Proposal #7 amendment]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 18:47:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 28 Jul 86 21:45:19-EDT
Date: Mon, 28 Jul 1986 21:45 EDT
Message-ID: <FAHLMAN.12226415324.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: [gls: Proposal #7 amendment]
This proposal from Guy Steele looks good to me. I think it checks a
reasonable amount of stuff and stops short of falling into the abyss.
-- Scott
---------------------------------------------------------------------------
Proposal #7 amendment
(1) First, not directly related to type specifiers, I propose a
primitive APPLICABLE that takes arguments just like APPLY, but rather
than actually doing the application it just returns T if the application
is okay with respect to argument-passing and NIL otherwise. This can be
build on top of FUNCTION-PARAMETERS.
(2) I propose that there be primitives TYPE-EXPAND and TYPE-EXPAND-1 that
are similar to MACROEXPAND and MACROEXPAND-1 but operate on type specifiers.
(3) I propose that TYPE-SPECIFIER-P behave as follows: if the argument
is a symbol, see whether it is a valid type specifier. If the argument
is a list whose car is a symbol, then there are two cases. If it is the
name of a primitive type specifier, then check the format of that type
specifier, using TYPE-SPECIFIER-P recursively where necessary. If it is
the name of a DEFTYPE, then use APPLICABLE to be sure that the type
specifier expansion function is getting valid arguments. If not, return
NIL; if so, then use TYPE-EXPAND-1 and recur on the result. In summary,
TYPE-SPECIFIER-P will make sure a DEFTYPE'd specifier has approximately
the right format, but if the code in the specifier function ever signals
an error then TYPE-SPECIFIER-P won't catch that.
∂28-Jul-86 2016 FAHLMAN@C.CS.CMU.EDU Proposal #5 status
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 20:16:38 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 28 Jul 86 23:16:37-EDT
Date: Mon, 28 Jul 1986 23:16 EDT
Message-ID: <FAHLMAN.12226431936.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal #5 status
In-reply-to: Msg of 28 Jul 1986 11:39-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
Can somebody PLEASE give me an example of (a) where this is useful and
(b) where this makes a difference?
In addition to parsing built-in body-taking forms, this would make it
relatively easy for the user to define new macros that take bodies and
declarations, with or without a doc string. It was pointed out long ago
that every implementation has something like this internally, so we
might as well make it accessible to users.
1. A documentation string (or NIL if none is present).
Why isn't the body first. What if there is more than one doc string?
Things appear in this order in the body (though the doc string and
declarations may be swapped), so people suggested that the returns
follow the "natural" order. It is an error if more than one doc string
is present (page 67).
2. A combined list of declaration specs, extracted from all
DECLARE forms found at the start of the body, whether present in the
body itself or obtained via macro-expansion.
I thought this was clear, at least in context. You get
((ignore a) (ignore b)), without the DECLARES.
?? I assume somebody has convinced themselves that the ordering or
separation of declares has no semantic meaning in CL?
Yes, unless you have a counter-example.
4. The macro-expansion for the first form in return value 3, if any.
Why the macroexpansion of the first form of the body? Why not the body
with the first form possibly expanded?
It saves a CONS.
Why not toss in the kitchen sink? It looks to me like
design-by-committee disease is striking.
Why is it always the guy who endlessly nit-picks every last unimportant
detail who accuses others of design by committee?
∂28-Jul-86 2044 FAHLMAN@C.CS.CMU.EDU Proposal #7 Status: TYPE-SPECIFIER-P
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 20:44:40 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 28 Jul 86 23:44:43-EDT
Date: Mon, 28 Jul 1986 23:44 EDT
Message-ID: <FAHLMAN.12226437059.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal #7 Status: TYPE-SPECIFIER-P
In-reply-to: Msg of 28 Jul 1986 11:10-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
It returns T if it is a meaningful second argument to TYPEP and NIL if
not. Is that specific enough?
No. "Meaningful" covers a lot of ground, some of it undecidable.
But Steele's proposal IS specific enough, in my view.
∂28-Jul-86 2053 FAHLMAN@C.CS.CMU.EDU Staus of proposals 10, 11, and 12
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 20:53:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 28 Jul 86 23:53:04-EDT
Date: Mon, 28 Jul 1986 23:53 EDT
Message-ID: <FAHLMAN.12226438578.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Staus of proposals 10, 11, and 12
In-reply-to: Msg of 28 Jul 1986 11:55-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
Proposal #10: Forms That Allow Declarations
I did question the need/usefullness of allowing declarations in
MACROLET. Nobody has responded and I still can't think of any.
It would come as a nasty surprise to people if MACROLET were different
from FLET and LABELS in this respect.
∂28-Jul-86 2055 NGALL@G.BBN.COM Re: Proposal #5 status
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 20:54:57 PDT
Date: 28 Jul 1986 23:52-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Proposal #5 status
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]28-Jul-86 23:52:11.NGALL>
In-Reply-To: <860728114007.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon, 28 Jul 86 11:40 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Sun, 27 Jul 1986 18:23 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
The default for documentation-allowed-p is NIL, meaning
that this form is NOT allowed to have a documentation string.
Can somebody PLEASE give me an example of (a) where this is useful and
(b) where this makes a difference?
As you point out, forms such as multiple-value-bind, flet, dotimes,
etc. are forms that 'are not allowed to have' or 'do not have'
doc-strings. Using your example:
(multiple-value-bind (a b)
(compute)
(declare (ignore a b))
"frob"
(compute-something-else))
This is still valid. It isn't the greatest style, but there is nothing
wrong with it. "frob" is a constant compiled for effect. As I
understand the current proposal, calling parse-body on the above "body"
would result in an error, which is wrong. The argument should be called
no-doc-string-p. It directs the parser to >>stop parsing<< when it
encounters a doc-string; it doesn't tell the parser to signal an error.
You misunderstood the current proposal. Calling parse-body with
doc-string-allowed-p true, would return "frob" as the doc-string, and
only one form in the list of 'body' forms. Calling parse-body with
doc-string-allowed-p false, would return nil as the doc-string value
and two forms (the first being "frob") in the list of body forms.
This is how doc-string-allowed-p makes a difference for legal bodies.
1. A documentation string (or NIL if none is present).
Why isn't the body first. What if there is more than one doc string?
Because the order of the values reflects the order of the components
of a body. Why should body be first? There can't be two doc-strings.
The second string in a body is always considered a form.
2. A combined list of declaration specs, extracted from all
DECLARE forms found at the start of the body, whether present in the
body itself or obtained via macro-expansion.
This isn't explicit enough. Do I get
((declare (ignore a))
(declare (ignore b)))
or do I get
(declare (ignore a)
(ignore b))
or do I get
((ignore a)
(ignore b))
You get the last alternative, 'a list of decl specs'; the other two
alternatives are declarations (which contain decl specs).
?? I assume somebody has convinced themselves that the ordering or
separation of declares has no semantic meaning in CL?
I assumed everyone had.
4. The macro-expansion for the first form in return value 3, if any.
Why the macroexpansion of the first form of the body? Why not the body
with the first form possibly expanded? Why should I always
,first-form-expanded ,@(rest body)
instead of
,@expanded-body
??
As was discussed, some macro expanders may want to see ALL body forms
(after decls and doc) before expansion, thus parse-body MUST return
all body forms unexpanded.
5. T if return 4 is a valid macro-expansion for the first form
in return 3, NIL otherwise.
What is an invalid macro expansion? What would this possibly be used
for? When could it possibly make a difference?
I suppose the same difference that the second value from macroexpand
could make.
Why not toss in the kitchen sink? It looks to me like
design-by-committee disease is striking. What functionality is useful
and needed, and what do we need to express it?
Ok, I'll bite, what?
-- Nick
∂28-Jul-86 2227 FAHLMAN@C.CS.CMU.EDU Proposed moratorium
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 22:27:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 29 Jul 86 01:27:26-EDT
Date: Tue, 29 Jul 1986 01:27 EDT
Message-ID: <FAHLMAN.12226455753.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposed moratorium
A significant fraction of the readers of this mailing list will be at
the Lisp Conference next week. Your moderator will be among them. We
all dread the thought of returning to blown-out mailboxes.
I would like to request that people refrain from sending technical
messages to Common-Lisp from Saturday, August 2, through Thursday,
August 7. This brief interlude can be used for catching up on old Common
Lisp mail, thinking up new issues, or interacting with the real world
(whatever THAT is). This is just a suggestion, but I can't guarantee
that mail arriving during that period will be looked at.
-- Scott
∂28-Jul-86 2308 RPG Mail Traffic
∂28-Jul-86 2237 FAHLMAN@C.CS.CMU.EDU Mail Traffic
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 22:37:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 29 Jul 86 01:38:01-EDT
Date: Tue, 29 Jul 1986 01:37 EDT
Message-ID: <FAHLMAN.12226457684.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Mail Traffic
In-reply-to: Msg of 29 Jul 1986 00:31-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
Wow!
Let's see how the next week goes, and then discuss what must be done in
Boston. Between the new dictatorial policy and the personal notes I
just sent to masinter and DCP, maybe we'll get a substantial reduction.
Perhaps splitting things up to more redistribution sites would help, but
we still have to get the volume under control.
The reforms haven't lightened my load too much, of course.
It may be that 2000 people can't design a language together if anyone
who wants to speak is allowed to. Still, I think tranquilizing about
four people would make a 50% difference if others didn't jump in to fill
the vacuum.
-- Scott